Включение разных библиотек для разных bin_Programs в autotool - PullRequest
1 голос
/ 21 января 2020

Мы создаем наши c ++ приложения с помощью Autotools. Мы создаем две bin_Programs в Makefile.am, как показано ниже:

bin_PROGRAMS = \ applications/A/a \ applications/B/b

В настоящее время мы включаем в обе эти программы одни и те же библиотеки, как показано ниже:

INCLUDES = -I@NE_ROOT@ -I@CORE_ROOT@/include @MYLIB_CFLAGS@ @BOOST_CFLAGS@ @LOG4CPP_CFLAGS@

Это определение @MYLIB_CFLAGS@:

MYLIB_CFLAGS=-I${mylib_include_dir}

Переменные в Makefile.am пусты, как показано ниже:

applications_A_a_SOURCES = 

applications_A_a_LDADD =

applications_A_a_LDFLAGS =

, и мы определяем те же переменные для программы b.

Я заметил, что программе b не требуется @MYLIB_CFLAGS@ во включениях, и при попытке обновить Glib c это вызывает проблемы. У меня вопрос, есть ли способ включить @MYLIB_CFLAGS@ для приложения "a", но не для приложения "b". `

1 Ответ

1 голос
/ 21 января 2020

В настоящее время мы включаем в обе эти программы одни и те же библиотеки, как показано ниже:

INCLUDES = -I@NE_ROOT@ -I@CORE_ROOT@/include @MYLIB_CFLAGS@ @BOOST_CFLAGS@ @LOG4CPP_CFLAGS@

В ваших интересах получить правильную терминологию, поскольку это сделает ее легче общаться с другими о таких проблемах и интерпретировать документацию, такую ​​как руководство Automake . С этой целью цель, предназначенная для обслуживания переменной INCLUDES, состоит в том, чтобы содержать флаги компилятора, которые указывают местоположения, которые должны появляться в пути поиска для директив C и C ++ #include, или которые служат аналогичным целям для компиляторов для Другие языки. Это только косвенно относится к библиотекам, и когда оно используется по назначению, оно, безусловно, не заставляет что-либо включать куда-либо.

Более того, и, более непосредственно связанное с вашим вопросом, это делает INCLUDES переменная является дополнением к различным *_CPPFLAGS переменным, которые более широко предназначены для использования для передачи флагов, предназначенных для модуляции поведения препроцессора. Это отличается от флагов, предназначенных для модуляции поведения самого компилятора, для которого обозначены *_CFLAGS (C), *_CXXFLAGS (C ++) и некоторые другие. Часто можно использовать неправильную переменную для передачи флагов, но это немного меняет дело. И, конечно же, не требуется придерживаться этих соглашений об именах для переменных, специфичных для проекта c, но я предпочитаю делать это, чтобы все было ясно.

Таким образом, учитывая ...

Это определение @MYLIB_CFLAGS @:

MYLIB_CFLAGS=-I${mylib_include_dir}

... единственным флагом, передаваемым этой переменной, является флаг -I, поэтому, если бы я делал именование эта переменная будет MYLIB_CPPFLAGS. Но это переменная c, определяемая проектом, поэтому значение ее имени зависит от того, что вы решите.

Переменные в Makefile.am пусты, как показано ниже:

Ну, это не очень полезно, и я подозреваю, что это на самом деле ввело вас в заблуждение. Нет необходимости указывать пустые переменные для Automake. Это не имеет другого значения для Automake, чем полное исключение переменной, но я подозреваю, что у вас могло сложиться впечатление, что значения, указанные в вашем Makefile.am, являются единственными доступными переменными для каждой цели. Они не. На самом деле, есть много больше, как указано в руководстве .

В частности, есть (условно) переменные applications_A_a_CPPFLAGS и applications_B_b_CPPFLAGS, где вы будет перечислять флаги препроцессора, которые определены c для одной цели или другой. Они накапливаются с переменными глобального эффекта, такими как INCLUDES, поэтому одним из способов решения описанной проблемы было бы изменить INCLUDES и добавить applications_A_a_CPPFLAGS, например:

INCLUDES = -I@NE_ROOT@ -I@CORE_ROOT@/include @BOOST_CFLAGS@ @LOG4CPP_CFLAGS@

applications_A_a_CPPFLAGS = @MYLIB_CFLAGS@

Теперь флаги в @MYLIB_CFLAGS@ будут использоваться только при сборке applications_A_a.

Также отмечу, что подозрительно, что вы говорите all переменные target-speci c, перечисленные в Makefile.am файл пуст. Это не обязательно неправильно, но обратите внимание, что библиотеки, которые не только для заголовков, также должны быть представлены в переменных компоновщика. Возможно, у вас есть переменная LDADD, по которой одни и те же библиотеки предназначены для всех целей (или, возможно, вы делаете это с AM_LDFLAGS, которая может работать при некоторых обстоятельствах, но будет некорректной, или, возможно, вы используете LDFLAGS, что быть хуже). Если вам нужно сделать это, то правильный способ назначить двоичные библиотеки, которые определены c для одной целевой программы или другой, будет через переменные applications_A_a_LDADD и applications_B_b_LDADD.

...