Отключение поддержки cxx для libtool после вызова AC_PROG_CXX

Question

Отключение поддержки cxx для libtool после вызова AC_PROG_CXX

Для моего проекта (библиотеки) я использую configure с libtool и automake для сборки под хостами linux. Библиотека состоит из C API, а также необязательного расширения C ++. Итак, с
AC_PROG_CXX должен вызываться глобально, я использую условные выражения automake:

*configure.ac*:

AC_PROG_CC
AC_PROG_CXX
AM_PROG_AR

LT_INIT

... some tests to figure out 'build_cxx' ...

AC_CONDITIONAL([CXX], [ test x$build_cxx = xyes ])

И внутри Makefile.am

sources = files.c
if CXX then
cxx_sources = files.cpp
else
cxx_sources =
endif

sources = $sources $cxx_sources

Однако все это не работает, когда configure не может найти g ++ (что практически убивает дополнительную логику для расширения c ++). После некоторых исследований я пришел к выводу, что AC_PROG_CXX так или иначе говорит libtool, что предполагается поддержка c ++. Я также был удивлен, осознав, что если AC_PROG_CXX завершается неудачей, он устанавливает для CXX значение «g ++» !!!

В любом случае, вызов AC_PROG_CXX условно приводит к ошибкам типа «am_fastdepCXX никогда не определяется», что мне кажется логичным. Хуже всего то, что ошибка не отображается во время работы configure, но она появляется позже на этапе компоновки, в виде неизвестного параметра libtool -o‘(ой).

Полный исходный код можно найти здесь -> http://bitbucket.org/sdlu/sdlu/src

Кто-нибудь может мне помочь?

Заранее спасибо…

0

automake autotools c++configure libtool

Решение

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

Я не думаю, что это хорошая идея вмешиваться в обработку переменной CXX.

Используйте свою собственную переменную BUILD_CXX

AC_CONDITIONAL([BUILD_CXX], [ test x$build_cxx = xyes ])here

а также

if BUILD_CXX
# ....
endif

0

Источник

Accepted Answer

Это ограничение Automake, оно не заботится о состоянии при выборе компоновщика.

Один из обходных путей — условно переписать команду _LINK, как предлагается в этот список рассылки:

if USE_CXX
cxx_sources = ...
else
cxx_sources =
libSDLU_la_LINK = $(LINK) $(libSDLU_la_CFLAGS) $(libSDLU_la_LDFLAGS)
endif

Другой способ (предложенный в том же обсуждении) — поместить исходные тексты C ++ в служебную библиотеку, которая создается и добавляется условно, а затем добавляется в основную библиотеку:

if CXX
noinst_LTLIBRARIES = libSDLUxx.la
libSDLUxx_la_SOURCES =  src/cxx/SDLU_CButton.cxx \
src/cxx/SDLU_CIniHandler.cxx \
src/cxx/SDLU_CRenderer.cxx \
src/cxx/SDLU_CSprite.cxx \
src/cxx/SDLU_CTexture.cxx \
src/cxx/SDLU_CWindow.cxx
libSDLU_la_LIBADD = libSDLUxx.la
endif

Не помещайте сгенерированные файлы (Makefile.in, configureи т. д.) в систему контроля версий.
Добавить bootstrap скрипт, который вызывает автоинструменты для генерации вещей.
Предпочитаю pkg-config (т.е. PKG_CHECK_MODULES(SDL2, sdl2)) над созданными вручную макросами autoconf (т.е. AM_PATH_SDL2);
Не устанавливайте автозаголовки (т.е. SDLU_config.h.in). Это делает вашу библиотеку несовместимой с любым программным обеспечением, основанным на autoconf, так как вы переопределяете PACKAGE, VERSIONи все макросы обнаружения библиотек. Увидеть мой ответ на этот вопрос примеры того, как это сделать.
Я бы собрал и установил C ++ API как независимую, необязательную библиотеку; полностью удалите скрипт sdlu-config, затем напишите sdluxx.pc что требует sdlu, Не надо проверять, работает ли компилятор C ++, если пользователь прошел --enable-cxx он знает, что делает; Я предпочитаю потерпеть неудачу при сборке, чем при незавершенной библиотеке.

1