2013-11-27 5 views
8

Я работаю над проектом C++, который использует autoconf & automake, и я изо всех сил пытаюсь правильно настроить пути включения в *CPPFLAGS. Я читал о документах на 3 часа, и пока не могу понять. Я не ищу взлома, но для правильного способа сделать это. Вот моя загадка.как установить включить пути с autotools

Как я вижу, есть 3 совершенно разные источники включают пути:

  1. Внешние библиотеки, которые должны быть установлены вместе с моим пакетом, которые настроены на configure --with-XXX=<PATH>.
  2. В моем пакете некоторые исходные файлы используют #include <file.h>, даже если file.h является частью пакета, поэтому для их компиляции я должен правильно установить путь включения. (Обратите внимание, что это не вариант для редактирования всех этих файлов.)
  3. Причудливые (или нет) стандарты указывают, что пользователю должно быть разрешено указать свои собственные (дополнительные) включенные пути. То есть, я не должен устанавливать CPPFLAGS.

В моей текущей настройке:

  • Тип 1 дорожка устанавливается внутри configure.ac по AC_SUBST(CPPFLAGS, "$CPPFLAGS -I<path>").
  • Пути типа 2 устанавливаются внутри Makefile.am по test_CPPFLAGS = -I<path>.
  • Тип 3 не может быть установлен. Точнее, если пользователь устанавливает CPPFLAGS перед запуском make, это переопределяет настройки типа 1, в результате чего компиляция завершится с ошибкой. Конечно, пользователь может попытаться использовать CXXFLAGS вместо этого, но у этого есть другое использование (помните, я прошу правильный способ сделать это, а не взломать).

Я попытался исправить это, установив пути 1-го уровня, используя AM_CPPFLAGS внутри configure.ac. (Для справки: если вы установили AM_CPPFLAGS вместо CPPFLAGS, но вам еще нужно выполнить некоторые проверки, такие как AC_CHECK_HEADERS, вам необходимо временно установить CPPFLAGS, а затем вернуть его для проверки, это объясняется here.) Это освобождает CPPFLAGS для путей типа 3, но, к сожалению, компиляция завершилась неудачно, потому что Makefile-s, который получает configure, будет использовать только AM_CPPFLAGS, если не существует специализированного <target>_CPPFLAGS. Итак, если test_CPPFLAGS существует с типом 2-го типа, компиляция test завершится неудачно, потому что он не получит путь типа 1.

Исправление должно указывать внутри Makefile.am, чтобы всегда использовать AM_CPPFLAGS. Но разве это «по книге»? Могу ли я сделать это глобально, или мне нужно редактировать каждый target_CPPFLAGS? Есть ли другое «правильное» решение?

+0

Под «причудливым» вы включаете официальную документацию по autoconf, в которой четко указано, что CPPFLAGS является пользовательской переменной, которая не должна быть модифицирована сопровождающим? (См. Раздел 4.8.1 на http://www.gnu.org/software/autoconf/manual/autoconf.html) –

+0

Хотя менее двусмысленный пример из официальной документации по автоману может быть более ясным, в котором говорится: «Вы никогда не должны переопределять пользовательская переменная, такая как CPPFLAGS в Makefile.am ». в разделе 27.6 на http://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html#Flag-Variables-Ordering –

ответ

18

Я знаю, что трудно получить прямой ответ из руководства по автообучению. Есть несколько хороших обучающих программ от начала до конца here и here.

В autoconf нет стандартной переменной для *CPPFLAGS для конкретного пакета. configure может быть вызван с CPPFLAGS=..., и automake добавит это CPPFLAGS к соответствующим правилам make-файла - найдите для примера CPPFLAGS в файле Makefile.in.По этой причине я предлагаю вам использовать , но не.

Добавить флаги в Makefile.am в переменную AM_CPPFLAGS (по умолчанию для всех вызовов препроцессора) или переопределить отдельные флаги препроцессора с помощью target_CPPFLAGS. В примере 3 библиотеки партии, то лучше использовать имя как: FOO_CPPFLAGS держать варианты препроцессора, например,

FOO_CPPFLAGS="-I${FOO_DIR}/include -DFOO_BAR=1" 
... 
AC_SUBST(FOO_CPPFLAGS) 

и в Makefile.am:

AM_CPPFLAGS = -I$(top_srcdir) $(FOO_CPPFLAGS) 
# or: 
target_CPPFLAGS = -I$(top_srcdir) $(FOO_CPPFLAGS) 

Переменная top_srcdir определяется configure - Я использую его, чтобы проиллюстрировать второй случай. Допустим, у вас есть file.h в другом каталоге other, в каталоге верхнего уровня. -I$(top_srcdir) позволяет включить его как <other/file.h>. Альтернативно, -I$(top_srcdir)/other позволит вам включить его как <file.h>.

Другой полезный preset variable: srcdir - текущий каталог. -I$(srcdir) добавляется к AM_CPPFLAGSпо умолчанию. Поэтому, если file.h находится в текущем каталоге, вы можете включить его с <file.h> или даже "file.h". Если other был «родным братом», -I$(srcdir)/.. позволит вам включить <other/file.h>, а -I$(srcdir)/../other позволит <file.h>.


Я бы также добавить, что некоторые пакеты установить карту PKG-CONFIG .pc файл. Если установка pkg-config настроена на поиск нужных каталогов, вы можете обнаружить, что макрос PKG_CHECK_MODULES очень полезен.

+2

Другим является '$ (builddir)' или '$ (top_builddir) 'который, по-видимому, предназначен для использования для любых файлов, созданных во время сборки. – CMCDragonkai

 Смежные вопросы

  • Нет связанных вопросов^_^