Хитрости и тонкости использования autotools

истинно верную систему автосборки

Бросай ее. cmake кошерней. Я бы даже сказал, она кошерно-халяльная ☺

ОП не читал?

А как обычно поступаете вы?

Берешь вывод find -name '*.c' -printf '%P\n' и вставляешь его в эту самую libname_la_SOURCES. Все компоненты сборки должны быть перечислены. Собирать «все файлы лабораторной работы с раширением *.c из текущей директории» ты замечательно можешь хоть наколенным shell-скриптом, для нормального проекта такое просто недопустимо.

Грабли, на которые часто наступают - не перечисляют заголовочные файлы в этих самых _SOURCES переменных. Если этого не сделать, то они не войдут в архив, создаваемый по make dist.

Другие грабли связаны с использованием VCS: вывод autoconf и automake ни в коем случае не должен лежать в VCS. Там должен быть только configure.ac (или .in - кому как нравится называть), Makefile.am и набор своих макросов. Конфигурационного файла (обычно config.h и config.h.in) тоже не должно быть в VCS.

Любителей ох*нного леса директорий также ждет разочарование: лучше написать один большой makefile, чем разрываеть логически единые единицы сборки по директориям. Т. е. если у тебя есть свои noinst_LIBRARIES, которые используются при сборке, это разумно каждую из библиотек собирать отдельным Makefile'ом, но если твой продукт разбросан по каталогам model/ view/ controller/, лучше иметь единый Makefile.am в каталоге верхнего уровня.

Ну и главный совет: проще всего начинать не с «чтения мануалов», а взять какой-то opensource проект, которому нужен сильно похожий на твой набор библиотек и творчески позаимствовать оттуда configure.in/ac скрипт.

Спасибо, анон!

Зачем?

Баг gmake и webkit (комментарий)

про хедеры не согласен с аноном их не в _SOURCES надо. есть же pkginclude_HEADERS либо include_HEADERS если надо, чтобы они по make install устанавливались (например, -devel пакеты делать) и noinst_HEADERS если только в make dist

указать просто шаблон типа *.c

разве где-то в документации automake сказано, что такие шаблоны в нём поддерживаются?

Затем. Какой вопрос - такой ответ.

Я считал это естественным... И да, tl;dr.

Зря ты недооцениваешь cmake

Да все с ним хорошо :)

А как же о грабли побиться? :)

Зря ты недооцениваешь cmake

cmake для ниосиляторов, autotools - стандарт де-факто. Мне лично нравится, что autotools-driven софт ведет себя стандартно, а cmake'овое (а также скунсовое, кумейковое и прочие бяки) ведут себя так, как посчитает нужным аффтар.

Если я хочу запаковать собранный проинсталлированный образ в архив для последующей распаковки где-то, с automake у меня есть DESTDIR. Для работы не в /usr/local autoconf скрипты имеют параметр --prefix. В цемейках и скунсах это остается «на усмотрение аффтара», потому что оба проекта были сделаны неосиляторами для неосиляторов. Пишешь гнутый софт, твой выбор autotools.

cmake для ниосиляторов

Тогда уж пиши Makefile ручками, осилятор хренов.

наредкость адекватный анон в этой ветке! бешено плюсую этот камент: Хитрости и тонкости использования autotools (комментарий)

если разберешься в автотулзах, не будешь так категоричен. иначе не надо фразу «мне лень/некогда/whatever» заменять на «cmake рулит» ;)

<offtop>как дела с stm?</offtop>

<offtop>как дела с stm?</offtop>

Пока забил: чертежи черчу.

Make it quick, make it dirty:

doit() {
echo -n «libname_la_SOURCES=»
for file in `ls *.c`; do
echo «$file \\»
done
}

doit > Makefile.am

Ну и эту магию можешь запрятать в bootstrap.sh