Нерекурсивный (нерекурсивный) Automake
Я пытаюсь преобразовать проект, чтобы использовать нерекурсивный automake. Основываясь на поиске по SO, я увидел, что эта тема была в некоторой степени раскрыта. Но на самом деле нет никаких вопросов о том, как преобразовать рекурсивный проект в автоматизированном режиме в нерекурсивный. Я уже прочитал Блог Карела Зака и конечно Autotools-Mythbuster. Есть вопрос с опыт в отношении нерекурсивного автомата но это не объясняет, как конвертировать проект. Единственный вопрос, который немного объясняет, похоже, касается опция subdir-объектов. Но я не смог преобразовать свой проект с этими ресурсами. Отсюда и этот вопрос.
Начнем с простой настройки проекта:
project/
\-- configure.ac
|-- Makefile.am
\-- src/
\-- Makefile.am
|-- foo.c
|-- foo.h
\-- main.c
В configure.ac Я просто добавляю subdir-objects опция:
AM_INIT_AUTOMAKE([subdir-objects])
В Makefile.am Я удалил src каталог из корня Makefiles.am«s SUBDIRS переменная. Затем я удалил src/Makefile запись от AC_CONFIG_FILES макрос в `configure.ac.
Блог Карела Зака предлагает назвать включенные Make-файлы из подкаталогов Makemodule.am но Makefile.am, кажется, тоже работает, если папка удалена для SUBDIRS переменная и если Makefile запись удалена из AC_CONFIG_FILES Конфигурационные файлы макросов.
Далее я определил глобальную переменную для программ в корне Makefile.am и включил src / Makefile.am
bin_PROGRAMS=
include src/Makefile.am
В src/Makefile.am Я изменился:
bin_PROGRAMS=foo
чтобы:
bin_PROGRAMS+=src/foo
и я также изменил все случаи foo_XXX в src_foo_XXX, И я добавил префикс src/ ко всем именам файлов .c и .h в src_foo_SOURCES,
Но программа не создавалась и выдает ошибки о том, что не найдены включаемые файлы, например:
fatal error: debug.h: No such file or directory
#include <debug.h>
Первоначально мои каталоги src Makefile.am содержали только переменные содержимого src_foo_SOURCES, src_foo_CFLAGS, src_foo_LDFLAGS а также src_foo_LDADD, Мое решение этой проблемы было добавить src_foo_CPPFLAGS как это:
src_foo_CPPFLAGS = \
$(AM_CPPFLAGS) \
-I$(top_builddir)/src \
-DDATADIR='"$(datadir)"' \
-DMODULEDIR='"$(moduledir)"' \
-DLIBEXECDIR='"$(libexecdir)"'
Но я не совсем понимаю, почему это было необходимо и почему оно работало нормально, когда я использовал рекурсивный automake?
У меня есть еще один вопрос относительно ответа Бретт Хейл в этом вопросе. Он пишет:
Вы можете использовать «$ (srcdir) /sourceA.cpp», но этот каталог в любом случае неявен. Все, что тебе нужно:
libadapter_la_SOURCES = sourceA.cpp sourceB.cpp
Но я не мог заставить его работать без префикса пути, так что мне это кажется неправильным, может ли кто-нибудь подтвердить мой опыт?
Обновить: У меня также есть проблемы с po/ subdir, как я могу сделать это нерекурсивным? Makefile.am не существует в po/ просто файл Makevars. Eсть пост на автоинструмент-мифбастер, это указывает на то, что нерекурсивная make с gettext не поддерживается, но это сообщение от 2011 года. Я не уверен, что что-то могло измениться за это время.
Решение
Начну снизу вверх: по отношению к gettext с 2011 года и po/ каталоги все еще должны обрабатываться рекурсивно, к сожалению. То же самое верно для gtk-doc, Причина в том, что они строят несколькоautomake-Совместим Makefile.in файлы, но они не очень automake-основан.
Что касается заголовочного файла, который не найден, причина, по которой он сейчас не работает, заключается в том, что вы используете неправильный #include Формат заявления: вы должны использовать #include "debug.h" и тогда это будет работать без добавления -Isrc в командной строке. Препроцессор будет искать "" вложенные заголовки в том же каталоге, что и исходный файл, и для <> вложенный заголовок в пути включения; automake по умолчанию добавляет текущий каталог к пути включения с -I. и это означало, что он был удовлетворен при использовании рекурсивного Makefile.am, но теперь «текущий каталог» больше не соответствует каталогу вашего исходного файла.
Я также предложил бы оба против повторного использования имени Makefile.am если вы используете предложенный Карел подход (automakeили, по крайней мере, некоторые его версии будут генерировать Makefile.in файл для подкаталога, который не будет работать должным образом), и рассмотреть вопрос о том, чтобы вообще не использовать подход Карела, если ваше программное обеспечение достаточно автономно, например, если оно имеет только одну двоичную цель. Случай использования Карела был linux-utils это довольно редкий проект с несколькими десятками целей, каждая из которых имеет свой собственный набор исходных файлов.
Я постараюсь прокомментировать ответ Бретта Хейла, который вы отметили, так как я думаю, что там вообще есть недоразумение.
Другие решения
detector