Корректная установка 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

Но это вряд ли официальный источник.

2

Решение

Вам нужно будет установить 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 это тестовый шум. Это требует больше инфраструктуры, но это то, что я предпочитаю. Я не рекомендовал бы такой подход, если вы не знакомы с автоинструментами.

1

Другие решения

Никогда Когда-либо установить автозаголовок 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.

8

По вопросам рекламы [email protected]