Корректная установка config.h для разделяемой библиотеки с помощью автоинструментов
Я конвертирую программу на C ++, которая использует систему сборки autotools для использования совместно используемой библиотеки, представляя введение в libtool. Большая часть функциональности программы размещается в разделяемой библиотеке, которая загружается основной программой, чтобы в будущем к общему коду могли обращаться другие программы.
Во всех источниках программы и библиотеки генерируется автозаголовок config.h используется с обычным макросом:
#if HAVE_CONFIG_H
# include <config.h>
#endif
В configure.ac я использую макрос для его генерации:
AC_CONFIG_HEADERS([config.h])
У меня вопрос, нужно ли устанавливать config.h чтобы другие могли использовать мою библиотеку, и если да, то как это сделать, и следует ли ее переименовать, чтобы избежать конфликтов и т. д.?
Больше всего информации я нашел здесь:
http://www.openismus.com/documents/linux/building_libraries/building_libraries#installingheaders
Но это вряд ли официальный источник.
Решение
Вам нужно будет установить config.h если это влияет на интерфейс. В практическом плане, если #defineтребуется заголовок (и), а не только .cc блоки реализации / компиляции.
Если config.h проблема, вы можете указать другое имя в AC_CONFIG_HEADERS макро. например., AC_CONFIG_HEADERS([foo_config.h]),
Самый простой способ установить заголовок, предполагая Automake, это с:
nodist_include_HEADERS = foo_config.h
на высшем уровне Makefile.am, nodist Приставка сообщает AutoMake, что foo_config.h генерируется, а не распространяется с пакетом.
Если не используете automake, установите foo_config.h в $includedir, $exec_prefix/include возможно, более правильный расположение сгенерированного заголовка, но на практике прежнее расположение хорошо.
Я избегаю использования config.h, передав соответствующие определения в CPPFLAGS или же foo_CPPFLAGS вместе с AC_SUBST в Makefile.am для исходных сборок, или AC_SUBST в foo.h.in генерировать заголовки во время настройки. Много config.h это тестовый шум. Это требует больше инфраструктуры, но это то, что я предпочитаю. Я не рекомендовал бы такой подход, если вы не знакомы с автоинструментами.
Другие решения
Никогда Когда-либо установить автозаголовок config.h,
Последнее, что нужно пользователям вашей библиотеки — это вмешательство макросов, вытекающих из вашего config.h, Ваша библиотека может иметь HAVE_FOOBAR, но мое программное обеспечение может быть скомпилировано таким образом, чтобы Foobar отключен, так что HAVE_FOOBAR сломает мою компиляцию.
Макрос AX_PREFIX_CONFIG из архива это обходной путь, где все становится с префиксом.
Лучшим подходом является создание файла шаблона (например, blargconfig.h.in) с такими строками:
typedef @BLARG_TYPE@ blarg_int_t;
@BLARG_RANDOM_INCLUDE@
А потом AC_SUBST() эти переменные в configure.ac:
AC_SUBST(BLARG_TYPE, ["unsigned short"])
AC_SUBST(BLARG_RANDOM_INCLUDE, ["#include <somerandomheader.h>"])
Затем перечислите его как выходной файл:
AC_CONFIG_FILES([Makefile
src/Makefile
...
include/blargconfig.h])
.h файл должен быть указан с nodist_include_HEADERS; .h.in файл будет автоматически распространяться, потому что он указан в AC_CONFIG_FILES,
Назначение для таких файлов обычно $libdir/packagename/include, Увидеть GLib например, хотя они генерируют glibconfig.h без шаблона (написав весь встроенный код создания в configure.ac, как автобук предлагает). Я считаю этот подход менее ремонтопригодным, чем использование AC_SUBST, но он более гибкий.
Конечно, чтобы помочь компилятору найти зависящий от платформы заголовок, вы, вероятно, также захотите написать скрипт pkgconfig, как это делает GLib.
detector