GNU Autotools иже с ними

Забудь про autotools, используй cmake.

просто почитай побольше, там не так сложно как кажется.

Ничего сложного - да, зато через жопу абсолютно все. cmake свободен от этих гнилых костылей, и умеет гораздо больше.

kdevelop :)

>Забудь про autotools, используй cmake.

Я не плюсофаг по типу тех людей из KDE4 и поэтому люблю делать все старомодно и аскетично.

>kdevelop :)

Anjuta тоже генерит кошерное дерево, но право же это нецелевое использование программы.

> cmake свободен от этих гнилых костылей, и умеет гораздо больше.

Неужто умеет больше автотулзов? Пруфлинк, конечно же, под рукой есть, да?

autoscan делает скелет с проверками заголовков и библиотек (входит в automake). Так что все дерево делается легко:
mkdir src; mkdir include
echo 'SUBDIRS = src include' > Makefile.am
(cd include; echo include_HEADERS = * > Makefile.am)
PROG=hello
(cd src; echo "bin_PROGRAMS = $PROG"; echo "${PROG}_SOURCES = " *.c) > src/Makefile.am
autoscan
mv configure.scan configure.in
Редактируем configure.in, там меняем maintainer, author, version, добавляем AM_INIT_AUTOMAKE(name, version)

aclocal && autoheader && automake && autoconf && ./configure

Условия добавить легко:
AC_ARG_WITH(debug, AC_HELP_STRING(--with-debug, [enable debug]),
[ CPPFLAGS="-DDEBUG=1 -g -O0 $CPPFLAGS" ])

О! Спасибо, толковый ответ.

> Я не плюсофаг по типу тех людей из KDE4 и поэтому люблю делать все старомодно и аскетично

И при чем же здесь плюсы, сподобишься объяснить? Ребята сделали инструмент, аналогов которому нет, а вы в силу убогости мышления или я не знаю чего до сих пор используете говнецо, которое из нечитабельных макросов генерит еще менее читабельные шаблоны makeфайлов и мегабайтный sh-скрипт, при этом этот кал еще и никогда не работает как надо.

> Неужто умеет больше автотулзов? Пруфлинк, конечно же, под рукой есть, да?

Я вас умоляю. Любой вменяемый разработчик должен подсознательно понимать, что в autotools что-то не так (а умный, что там ВСЕ не так). Если ты в танке, начни вот с этого:

http://www.elpauer.org/stuff/learning_cmake.pdf

Не так в первую очередь всё с Си и сишным подходом к библиотекам.

А нетакливость autotools - всего лишь следствие.

>Ребята сделали инструмент, аналогов которому нет, а вы в силу убогости мышления или я не знаю чего до сих пор используете говнецо, которое из нечитабельных макросов генерит еще менее читабельные шаблоны makeфайлов и мегабайтный sh-скрипт, при этом этот кал еще и никогда не работает как надо.

Я обычно выступаю в роли пользователя и вообще говоря меня всегда сильно коробит разбираться как мне сделать spec файл (а кому-то ебилд или что там в дебиане) в рамках очередной гениальной системы сборки от каких-либо чудаков.

>И при чем же здесь плюсы, сподобишься объяснить?

Все инновации в билдостроении обычно приходят с плюсов, наверно они думают что ихняя проблема - это билдостроение.

Извините, но вы ламер :)

> Я обычно выступаю в роли пользователя и вообще говоря меня всегда сильно коробит разбираться как мне сделать spec файл (а кому-то ебилд или что там в дебиане) в рамках очередной гениальной системы сборки от каких-либо чудаков

В случае с CMake все предельно просто, но:
- сложновато найти примеры
- недавно были небольшие изменения интерфейсов.

Мде, автотулз уже давно пора на помойку истории. Даже хрен с ней, с простотой. Но тащить полметра с прогой в 20 килобайт это уже явный перебор. Даже qmake+qconf выглядит куда лучше.

> сложновато найти примеры

ОЧень просто.
http://www.google.com/codesearch?q=file%3ACMakeLists.txt&hl=en&btnG=S...

> Не так в первую очередь всё с Си и сишным подходом к библиотекам.

Подробней, пожалуйста.

> очередной гениальной системы сборки от каких-либо чудаков.

Чудаки - те, кто пользуется устаревшей рухлядью. А спеки cpack сам генерит.

> Все инновации в билдостроении обычно приходят с плюсов, наверно они думают что ихняя проблема - это билдостроение.

Тоже не осилил потока сознания. При чем тут вообще плюсы?

>> очередной гениальной системы сборки от каких-либо чудаков.

>Чудаки - те, кто пользуется устаревшей рухлядью.

Юниксу вообще скоро сороковник.

>> Все инновации в билдостроении обычно приходят с плюсов, наверно они думают что ихняя проблема - это билдостроение.

>Тоже не осилил потока сознания. При чем тут вообще плюсы?

Еще раз: Все инновации в билдостроении обычно приходят с плюсов. Это только для плюсового барахла обязательно надо cmake/scons/jam какой-нибудь выкачать, сидеть разбираться с ними еще. В то же время проекты на Си всегда элементарно собираются с пол-пинка.

Знаешь, мы с Сергеем тоже любили autools, его особую, винтажную атмосферу, словно прикасаешься к забытому знанию, и оно озаряет тебя мягким светом таинственной мудрости. Но однажды Серёжа сказал: «Нельзя жить прошлым, надо смотреть вперёд». И он был прав, мужчина всегда должен смело смотреть в будущее, не отворачиваясь, не отводя глаз, даже если страшно, даже если ветер выжимает слёзы из глаз. В тот вечер мы любили друг друга до умопомрачения, словно прощаясь, а утром перевели свой проект на CMake. Сергей стал миллиардером в свои 25, и я думаю, тебе есть, чему у него поучиться.

> Это только для плюсового барахла обязательно надо cmake/scons/jam какой-нибудь выкачать, сидеть разбираться с ними еще.

Ты и правда клинический идиот. Сборка C++ проектов _ничем_ не отличается от сборки C проектов. А в автоговне разбираться нужно (особенно для нетривиальных вещей) много дольше, чем в cmake.

> В то же время проекты на Си всегда элементарно собираются с пол-пинка.

Тогда какого ж хрена ты тут просишь `утилиту, которая бы генерировала дерево проекта GNU Autotools по простым опциям'? Небось неохота Makefile.am руками дрочить для каждой директории? От этого cmake избавляет в том числе.

> Еще раз: Все инновации в билдостроении обычно приходят с плюсов

Ага, особенно Ant и Maven %)

>> Еще раз: Все инновации в билдостроении обычно приходят с плюсов

>Ага, особенно Ant и Maven %)

Жаба вообще суть отдельная ОС и поэтому разумно что она склонна иметь отдельные тулы.

>>> Еще раз: Все инновации в билдостроении обычно приходят с плюсов

>> Ага, особенно Ant и Maven %)

> Жаба вообще суть отдельная ОС и поэтому разумно что она склонна иметь отдельные тулы.

Несколько видов make (GNU, BSD, nmake), cake, rake, bake, jam, scons - тысячи их, и все для Си (ладно, rake - для Руби).

> Это только для плюсового барахла обязательно надо cmake/scons/jam какой-нибудь выкачать, сидеть разбираться с ними еще. В то же время проекты на Си всегда элементарно собираются с пол-пинка.

"cmake ." или "ccmake ." не сложнее, чем "./configure", при этом работает быстрее и может работать в отдельном каталоге, при этом папка с сорцами остается абсолютно чистой. Ах да, оно еще и под виндой хорошо работает.

>> сложновато найти примеры
> ОЧень просто.

Боевые примеры частенько рвут мозг, к тому же, порой нужный функционал используется лишь в 1 из 50 проектов. Именно поэтому хороший пример можно искать весьма долго.

Ну, кстати, configure тоже можно из другого каталога запускать.

>Несколько видов make (GNU, BSD, nmake), cake, rake, bake, jam, scons - тысячи их, и все для Си (ладно, rake - для Руби).

Да да да, и у каждого свой птичий быдлоязычок. Я конечно не могу покончить с этим раз и навсегда, но могу использовать наиболее обкатанное решение к которому привыкло наибольшее число пользователей.

> Боевые примеры частенько рвут мозг

На cmake не рвут. Все что мне до сих пор было нужно либо юзабельно as-is, либо оттуда сразу понятно что и как делать.

> Ну, кстати, configure тоже можно из другого каталога запускать

Пардон, я немножко тупанул, действительно, можно, начиная с configure(?). Однако, в CMake это делается красивее, потому что кроме CMakeLists.txt в сорцах ничего не нужно. При работе с RCS это весьма упрощает жизнь.