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

0

Для моего проекта (библиотеки) я использую 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 " (ouch).

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

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

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

Теги:
autotools
automake
libtool
configure

2 ответа

1
Лучший ответ

Это ограничение 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

Некоторые несвязанные заметки

  1. Не помещайте сгенерированные файлы (Makefile.in, configure и т.д.) В исходный элемент управления.

  2. Добавьте скрипт bootstrap который вызывает autotools для генерации вещей.

  3. Предпочитаете pkg-config (т.е. PKG_CHECK_MODULES(SDL2, sdl2)) по макросам с AM_PATH_SDL2 вручную (т.е. AM_PATH_SDL2);

  4. Не устанавливайте autoheaders (например, SDLU_config.h.in). Это делает вашу библиотеку несовместимой с каждым программным обеспечением на основе autoconf, поскольку вы переопределяете PACKAGE, VERSION и все макросы обнаружения библиотек. См. Мой ответ в этом вопросе для примеров о том, как это сделать.

  5. Я бы установил и установил C++ API как независимую, дополнительную библиотеку; полностью отключите скрипт sdlu-config, затем напишите sdluxx.pc, для которого требуется sdlu. Не утруждайте себя проверкой работы компилятора C++, если пользователь прошел через --enable-cxx он знает, что он делает; Я предпочитаю, чтобы сборка была неудачной, чем незаполненная библиотека.

Поделиться
  • 0
    Спасибо за ваш ответ, первый обходной путь (смена команды LINK) отлично сработал для меня. Что касается примечаний:
  • 0
    1-2 : Я решил добавить сгенерированные файлы, чтобы избежать общей проблемы с различными несовместимыми версиями автоинструментов. 3 : Эти макросы внутренне используют pkg-config и откат к соответствующим сценариям (sdl2-config). 4 : Это исправлено. в последней версии спасибо за то, что отметили 5 : я хотел бы избежать этого и использовать его только в качестве крайней меры, главным образом потому, что я также поддерживаю системы сборки на основе CMake и premake. Еще раз спасибо!
Показать ещё 2 комментария
0

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

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

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

а также

if BUILD_CXX
  # ....
endif
Поделиться
  • 0
    Нет, это не проблема ... Использование CXX прекрасно работает как условное имя

Ещё вопросы

Сообщество Overcoder
Наверх
Меню