Вышел (http://lists.gnu.org/archive/html/automake/2012-12/msg00038....) релиз Automake 1.13 (http://www.gnu.org/software/automake/), утилиты для автоматической генерации make-файлов, соответствующих стандартам кодирования проекта GNU. Кроме исправления ошибок и добавления новшеств в новой версии отмечена большая порция возможностей, поддержка которых будет прекращена в следующем выпуске, что приведёт к нарушению обратной совместимости.
В частности, работа Automake 1.14 скорее всего будет возможна только вкупе с ещё не выпущенной версией пакета Autoconf 2.70, будет прекращена поддержка имени 'configure.in' в качестве входного файла для Autoconf, будет удалён m4-макрос AM_PROG_MKDIR, будет объявлена устаревшей переменная сборки ACLOCAL_AMFLAGS, будет прекращена поддержка C/C++ компилятров IRIX и SGI, будет удалена поддержка MS-DOS и Windows 95/98/ME, будет прекращена поддержка переменной INCLUDES (следует использовать AM_CPPFLAGS), скрипты будут рассчитаны на работу с POSIX shell, все внешние m4-файлы (в директориях $ACLOCAL_PATH и aclocal) будут иметь более высокий приоритет по сравнению во встроенными макросами.
Из новшеств GNU Automake 1.13 можно отметить:- Для работы требуется Autoconf начиная с версии 2.65 и Texinfo 4.9;
- Прекращена (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11034) поддержка деревьев в стиле Cygnus (режим "--cygnus");
- Для улучшения поддержки VPATH, сборки поддиректорий и одновременной работы компонентов пересмотрены средства байт-компиляции Elisp;- По умолчанию активирован тестовый комплект, поддерживающий параллельное выполнение тестов;
- Пользователю предоставлена возможность определения рекурсивных целей, используя для этого m4-макрос 'AM_EXTRA_RECURSIVE_TARGETS';
- Существенно изменена семантика скрипта 'missing', который теперь выводит более ясные сообщения диагностики и не пытается обновить данные о времени устаревших файлов, требующих пересборки специфичных инструментов мэйнтейнера;
- Макросы AC_CONFIG_MACRO_DIR и AC_CONFIG_MACRO_DIRS могут использоваться для определения директорий для включения локальных m4-файлов;
URL: http://lists.gnu.org/archive/html/automake/2012-12/msg00038....
Новость: http://www.opennet.me/opennews/art.shtml?num=35721
Удивительно что оно ещё развивается, да ещё и ломая совместимость, в то время как ни один новый проект в здравом уме не будут собирать этой пакостью, когда есть cmake, и нужно оно только для поддержки легаси.Для статистики (из FreeBSD портов):
2010-12-31: autotools: 5106, cmake: 268
2012-12-29: autotools: 4899, cmake: 450буквально вот вчера обновили supertuxkart, который тоже перешел с autocrap на cmake.
> Для статистики (из FreeBSD портов):Учитывая религиозную ненависть FreeBSD к GNU - не показатель.
Во-первых, не надо свои тараканы на других переносить, никакой ненависти нет.
Во-вторых, для тех кто в танке: в портах находится сторонее ПО под любыми лицензиями.
> Во-первых, не надо свои тараканы на других переносить, никакой ненависти нет.Оно и заметно - из-за любви переходят на компилер который генерит более паршивый код.
> 2010-12-31: autotools: 5106, cmake: 268
> 2012-12-29: autotools: 4899, cmake: 450
>с autocrap на cmake.За джва года cmake стал ещё лучше! Был в 20 раз хуже, теперь только в 10!! Ура?
Ванга намекает, что сейчас будет про "миллионы мух".
>> 2010-12-31: autotools: 5106, cmake: 268
>> 2012-12-29: autotools: 4899, cmake: 450
>>с autocrap на cmake.
> За джва года cmake стал ещё лучше! Был в 20 раз хуже,
> теперь только в 10!! Ура?cmake всегда был лучше. А статистика показывает что не только новые проекты избегают autocrap, но и старые с него сваливают ударными темпами.
А у вас осталась запасная пара розовых очки для детекта ударных темпов?
>>> 2010-12-31: autotools: 5106, cmake: 268
>>> 2012-12-29: autotools: 4899, cmake: 450
>>>с autocrap на cmake.
>> За джва года cmake стал ещё лучше! Был в 20 раз хуже,
>> теперь только в 10!! Ура?
> cmake всегда был лучше. А статистика показывает что не только новые проекты
> избегают autocrap, но и старые с него сваливают ударными темпами.Угу. Только вменяемого лога от него добиться, если что-то пошло не так - то ещё удовольствие. И список конкретных тестов, которые оно провело, и их результатов - тоже так просто не видно. В отличие от autotools, в которых всё нагляднее некуда.
Видел ваши опусы в треде о GnuTLS, постыдились бы ламерствовать дальше. Всё там видно, загляните в CMakeFiles/. И в читабельном формате, в отличие от простыни мусора от autocrap.
> Видел ваши опусы в треде о GnuTLS, постыдились бы ламерствовать дальше. Всё
> там видно, загляните в CMakeFiles/. И в читабельном формате, в отличие
> от простыни мусора от autocrap.Да у человека GNU головного мозга. Будет до пены у рта защищать даже autocrap.
да будь он десять раз крап - если из его вывода я вижу, где что сломалось, а CMake выводит тупое сообщение, что проблема есть, и ноль деталей - мне такого счастья не надо. И красот его тоже не нужно. Тупо лог всего, что запускалось, со строками запуска.
Кстати, с инопланетностью языка автотулзов я ни разу не спорю - мутная система на редкость. Но из того, что мне попадалось как пользователю- они единственные дают возможность удобно диагностировать проблемы билда и при необходимости поправить что-то. И config.log, и довольно простая возможность модифицировать макросы чтобы они выплевывали код генерируемых тестовых программ в файл, и то, что вывод всего и вся сыпется в одну консоль и может быть запросто завернут куда-то - это всё очень удобно.
Да уж. Мало того что cmake и его проверки глючные, так еще и въезжать что ему не хватило - отдельный геморрой. Сообщения нифига не очевидные и его работа нифиг не прозрачна. И как бы там ни ругали автокрап (который реально на птичьем языке пишется), этот момент у них проработан лучше других. Вот все и кушают кактус. Матерятся, но кушают.
> Да у человека GNU головного мозга. Будет до пены у рта защищать даже autocrap.На практике автокрап получше cmake-а работает. Cmake вообще горбатый и регулярно валится так что хрен поймешь чего не хватило. Автокрап по крайней мере нормально информирует что не так и по минимуму пошлет на любой системе где есть шелл. А вот cmake - и зависимостей для взлета больше, и детектирование чего не хватило жутко горбатое. И остальные "убийцы" - не лучше.
Вы того, заканчивайте вещества употреблять.Во-первых, вы меня с кем-то совершенно сурово попутали. Я в том треде не писал, насколько я помню.
Во-вторых - что я где увижу, какой, к чертям, "другой формат", если мне нужно видеть, на чем сломался билд - то есть вывод того, что из мейк-файлов запущено было? А CMake этого не выводит. Скорее всего можно как-то заставить, но подход автотулзов, когда вывод, который должен быть в консоли, там и есть, мне нравится гораздо больше.
Полностью согласен, через раз cmake тереят -ld параметр линковки, в автоконфе в таких случаях даже лезть никуда не надо, уже помню какие функции откуда линкуются, просто из шелла последнюю команду запускаю с добавлением -ld и снова make и делов-то; в этой пестрой уйне я по 2-3 часа затупляю в ее конфиги чтобы понять какого хера ей надо, откуда она извлекает пути к библиотекам, где флаги копиляции менять, а кэширование ее тотальное это просто песня- не собралось с первого раза, пересобирай, а то и перераспаковывай, короче прозрачности 0.
> За джва года cmake стал ещё лучше! Был в 20 раз хуже,
> теперь только в 10!! Ура?Митрофанушка как всегда на коне, браво!
> Митрофанушка как всегда на коне, браво!Ну а кто виноват что тут кормят хорошо? :)
> Для статистики (из FreeBSD портов):Опрос по статистике пакетов ubuntu показал, что 100% пакетов используют инфраструктуру Launchpad.
>> Для статистики (из FreeBSD портов):
> Опрос по статистике пакетов ubuntu показал, что 100% пакетов используют инфраструктуру
> Launchpad.Что сказать-то хотели? FreeBSD порты всего лишь используют систему сборки апстрима, соотсвтственно просто отражают использование систем сборки на некоторой выборке программных пакетов. Для совсем безграмотных - выборка никак не зависит от лицензии.
Можете посмотреть в portage или AUR - там будет то же самое.
Не знаю как там целиком в портаже - но в том, что у меня на машине, отношение autotools/cmake навскидку примерно 20 к 1. Если не круче.
> Не знаю как там целиком в портаже - но в том, что
> у меня на машине, отношение autotools/cmake навскидку примерно 20 к 1.
> Если не круче.И? Вы как митрофанушка, оцениваете популярность инструментов по общей доле? Если бы autocrap работал, cmake чтобы набрать столько же проектов сколько используют autocrap понадобилось бы столько же времени сколько лет autocrap'у, и это нормально, потому что не за чем трогать работающие вещи. Но что парадоксально, с autocrap драпают сотрями проектов в год. Почему, как вы думаете?
> Если бы autocrap работал, cmake чтобы набрать столько же проектов сколько используют autocrap понадобилось бы столько же времени сколько лет autocrap'уу аутокрапа в своё время было одно преимущество - оно было единственной системой сборки продолжительное время, потому на нём почти все более-менее древние проекты.
А сейчас уходить с autotools'ов можно не только на cmake, да и существенно лучшей замены аутотулзам всё ещё нет. cmake это аналогичное насилование make файлов, со своими минусами и с совсем небольшим кол-вом фичь.
Не будет у cmake никогда такой же популярности, как у autotools. В относительно ближайшее время появятся полные альтернативы системам на make файлах и весь апстрим будет уже переходить на них.
> Но что парадоксально, с autocrap драпают сотрями проектов в год.
2 по сравнению с 1 даёт +100 %, однако единица остаётся единицой несмотря на 100 %
> А сейчас уходить с autotools'ов можно не только на cmakeТолько. scons - не система сборки, а кривой скрипт на питоне, waf - то же самое, только ещё маргинальнее и ничего не умеет, ant - java, qmake - qt и также ничего не умеют. Больше ничего нет.
> cmake это аналогичное насилование make файлов, со своими
> минусами и с совсем небольшим кол-вом фичьМинусов там нет, и фич там гораздо больше чем у autocrap. Начнём с определения системы сборки - она должна:
- по описанию, состоящему из фактов (а не костылей)
- собрать софт
- под любой системой
- учитывая внешние зависимости
- причём этот процесс должен быть управляемымИз существующих систем сборки этому списку удовлетворяют только autocrap и cmake. Например, scons не ищет изкоробки врешние зависимости, и очень плохо управляется (чтобы можно было указать при сборке свои CC/CFLAGS/CXX/CXXFLAGS/CPPFLAGS/LDFLAGS нужно писать свой код. много кода. равно как и для поддержки всех разичий между системами).
При этом cmake однозначно уделывает autocrap по 1 пункту, потому что покуда autocrap даже в исходнике - кошмарное нагромождение макросов в куче файлов (не считая того ада, где эти макросы определяются), CMakeLists.txt - список голых фактов (FIND_PACKAGE, ADD_EXECUTABLE, TARGET_LINK_LIBRARIES - всё, сложнейший проект с кучей зависимостей собран). По третьему и сразу второму пункту - cmake генерит не только makefile, так что только он может собрать софт используя нативные инструменты (родной VC под виндой, вместо установки unix окружения). Четвёртый в cmake тоже лучше - все внешние библиотеки он просто находит, без необходимости указывать CPPFLAGS/LDFLAGS если библиотеки ставятся в /usr/local как на *bsd, например. Последнее у autocrap и cmake примерно на одном уровне.
При всём этом у cmake в коробке куча дополнительных фич, начать можно с ctest и cpack.
> Не будет у cmake никогда такой же популярности, как у autotools
Уже есть. Популярность, если что, это процент новых проектов. А все новые проекты, если что, выбирают cmake. А у autocrap, если что, популярность сейчас отрицательная.
(Ни в каком месте не агитирую за autotools)> - по описанию, состоящему из фактов (а не костылей)
> ...
> При этом cmake однозначно уделывает autocrap по 1 пункту,Решительно не согласен. По этому пункту cmake представляет из себя аналогичный набор ad-hoc костылей (очень близкий к тому, что сделано в autotools).
> Из существующих систем сборки этому списку удовлетворяют только autocrap и cmake.
autocrap не удовлетворяет п.3 ("под любой системой").
> CMakeLists.txt - список голых фактов (FIND_PACKAGE...
Отработка которых реализована через тот же самый набор костылей. Для примера можно посмотреть, на основе каких т.н. "фактов" в CMake делается вывод о наличии boost'а.
> По этому пункту cmake представляет из себя аналогичный набор ad-hoc костылей (очень близкий к тому, что сделано в autotools)
> на основе каких т.н. "фактов" в CMake делается вывод о наличии boost'а.Пустые слова. В чём адхочность и костыльность? Что вам не нравится в FindBoost.cmake?
Спор ни о чём.cat configure.ac
....
BOOST_REQUIRE([1.46])
BOOST_PROGRAM_OPTIONS
#BOOST_SYSTEM
BOOST_FILESYSTEM
...
>> По этому пункту cmake представляет из себя аналогичный набор ad-hoc костылей (очень близкий к тому, что сделано в autotools)
>> на основе каких т.н. "фактов" в CMake делается вывод о наличии boost'а.
> Пустые слова. В чём адхочность и костыльность? Что вам не нравится в
> FindBoost.cmake?55k ни о чем. Хотя простой и однозначный ответ получается после
#include <boost/filesystem/operations.hpp>
в тексте моей программы.
>> А сейчас уходить с autotools'ов можно не только на cmake
> Только. scons - не система сборки, а кривой скрипт на питоне, waf - то же самое, только > ещё маргинальнее и ничего не умеет, ant - java, qmake - qt и также ничего не умеют.
> Больше ничего нет.Легковесных альтернатив больше, чем может показаться.
mk-configure, например. Автокрап нерелевантен совершенно.
https://github.com/cheusov/mk-configure
> Больше ничего нет.http://msteveb.github.com/autosetup/
да, это *не полная* замена. но вполне замена autoconf (который, в большинстве, и ругают, когда ругают autocrap) для очень многих случаев. а также, например: http://industriousone.com/premake
ну, и других есть, если поискать. и очень часто их действительно *достаточно* для замены как минимум autoconf, а то и autoconf/automake целиком.так что не надо про «больше ничего нет», неправда это.
cmake тот же самый крап, но немного более адекватный. И таки да, 4899 смотрит на ваши 450 как на гогно
> cmake тот же самый крап, но немного более адекватный. И таки да,
> 4899 смотрит на ваши 450 как на гогноНет, на гoвно смотрит +200 и рост в два раза cmake на -200 аутокрапа. Но вы можете фапать на накопленную критическую массу.
Сама идея генерить make файлы порочна.
Несусветная чушь.
> Сама идея генерить make файлы порочна.Чтобы не генерить - должно околеть напрочь вообще все кроме 1-2 видов архитектур и систем. Что тоже порочно по смыслу.
>> Сама идея генерить make файлы порочна.
> Чтобы не генерить - должно околеть напрочь вообще все кроме 1-2 видов
> архитектур и систем. Что тоже порочно по смыслу.Скорее наоборот: генережка make-файлов необходима только одной системе --- W., ибо только на ней отсутствует возможность нормального скриптования.
>>> Сама идея генерить make файлы порочна.
>> Чтобы не генерить - должно околеть напрочь вообще все кроме 1-2 видов
>> архитектур и систем. Что тоже порочно по смыслу.
> Скорее наоборот: генережка make-файлов необходима только одной
> системе --- W., ибо только
> на ней отсутствует возможность нормального скриптования.Люто плюсую, черт побери! Кодогенерация для систем
сборки -- чистой воды идиотизм.
> Удивительно что оно ещё развивается, да ещё и ломая совместимость, в то
> время как ни один новый проект в здравом уме не будут
> собирать этой пакостью, когда есть cmake, и нужно оно только для
> поддержки легаси.
> Для статистики (из FreeBSD портов):
> 2010-12-31: autotools: 5106, cmake: 268
> 2012-12-29: autotools: 4899, cmake: 450Странно было бы другого ожидать. cmake - как глоток чистого воздуха, и аналогов ему сейчас нет.
> Странно было бы другого ожидать. cmake - как глоток чистого воздуха,Глоток выхлопных газов когда что-то не прокатило и фиг поймешь по его выводу чего именно.
Пф. Я всегда предпочитаю Autotools. Любой специалист в здравом уме понимает, что Autotools - отличный инструмент, и только неосиляторы-наколенники исходят на говно.
> Любой специалист в здравом уме понимает, что Autotools — отличный инструменткак хорошо, что я не работаю с такими «специалистами в здравом уме».
I saw a book entitled "Die GNU Autotools" and I thought "My feelings exactly". Turns out the book was in German. ©
autotools, IMNSHO, были и остаются ярким примером over-engineering.- только unix-подобные системы
- HAVE_SOMETHING в коде даже если и использовались, то там все равно писалась
ветка под конкретную систему (т.е. многочисленные тесты гонялись
впустую, решение всё равно сводилось к выбору на основе 'uname -a')
- самосовместимость autotools ниже плинтуса --- очень редкие версии
вытерпят друг друга
> - только unix-подобные системыи где же здесь 'over-engineering' ?
> HAVE_SOMETHING в коде даже если и использовались...
и здесь? Это же просто результат лютого быдлокода на m4 скриптах.
autotools были первой популярной системой сборки, развивались стихийно на коленках, примерно как сейчас php. Никто особо не задумывался над архитектурой проекта и его юзабилити, со временем маленький ком дерьма стал большим. Весь фокус.от over-engineering'а в них разве что потуги GNUшников делать свои проекты работоспособными на широком круге ОС, не только на юниксоподобных, прошу заметить.
> и где же здесь 'over-engineering' ?Частично принято ;)
Там огромное количество бесполезных тестов. Ну, и 'friends' --- всякие libtools до кучи.
> Там огромное количество бесполезных тестов.не «бесполезных», а «бесполезных, потому что устарели». что, конечно, не отменяет основного — их бесполезности.
Лошопеды, Makefile руками пишутся!
Согласен. Зачем куча инструментов, освоить которые, а потом ещё использовать, гораздо сложнее, чем создать список *.c файлов, откомпилировать и слинковать? При том, что эти инструменты постоянно пытаются убежать от обратной совместимости.
Представьте себе ситуацию, в которой пианист пытается научиться играть на пианино, которое всё время меняет форму, размер и положение клавиш, высоту сиденья и положение педали. Мало того, разработчики этого чуда пианино придумали замечательную фичу: чем чаще нажимается та или иная клавиша, тем ближе она располагается к указательному пальцу. Более того, было решено в каждой новой версии пианино автоматически удалять с клавиатуры клавиши, которые в предыдущих двух и более подходов пианиста к пианино не нажимались.
Вот нарвётесь на какие-нибудь неочевидные зависимости - поймёте. Ну там - файлы include с одинаковыми именами, но по сути - разные (от разных версий библиотеки или вообще от разных библиотек). Или на библиотеки, собранные с разными флагами, из которых вам подходятдалеко не все. Или на компиляторы, которым надо скармливать разные флаги. Или когда на разных платформах библиотека предосталяет разный функционал, причём кое-где ещё и бажный (канонический пример - poll/select/kqueue/epoll)... Да вагон вариантов. Оно да, на локалхосте "чисто для себя" и обойтись можно. Если не думать, что софтина должна собираться у кого-то другого.
> Вот нарвётесь на какие-нибудь неочевидные зависимости - поймёте.Поддерживаю Главных Редакторов.
Сделать "из первых принципов" гораздо проще и быстрее, чем прорываться через наслоения autotool'зов.
Ну, и таки да, нарывался --- уговорить "неочевидные" вещи в auto... --- тройная работа (сделать неочевидную вещь, разобраться, куда ее можно подоткнуть в autotools, сделать с autotools). Причем разобраться в autotools --- самое трудоемкое.
Оно мерзкое в написании, согласен, и осваивается паршиво и-за отсуствия высокоуровневого описания. Но из того, что видел - самое удобное потом в пользовании. Особенно - если надо разрулить какие-то проблема
> Вот нарвётесь на какие-нибудь неочевидные зависимости - поймёте.Если майнтейнер PupkinLinux решил запихуть хедеры <sys/> и <asm/> в /usr/include/mysystem, /usr/include/assembler
а библиотеки в /usr/lib-pupkin/64bit, это его личные сексуальные проблемы, для нормальных существуют стандарты!
> Вот нарвётесь на какие-нибудь неочевидные зависимости - поймёте. Ну там - файлы
> include с одинаковыми именами, но по сути - разные (от разных
> версий библиотеки или вообще от разных библиотек). Или на библиотеки, собранные
> с разными флагами, из которых вам подходятдалеко не все. Или
> на компиляторы, которым надо скармливать разные флаги. Или когда на разных
> платформах библиотека предосталяет разный функционал, причём кое-где ещё и бажный (канонический
> пример - poll/select/kqueue/epoll)... Да вагон вариантов. Оно да, на локалхосте "чисто
> для себя" и обойтись можно. Если не думать, что софтина должна
> собираться у кого-то другого.Все перечисленное не убеждает лично меня, что для решения этих
проблем нужно было написать такое г., как autotools.
Вот https://github.com/cheusov/mk-configure
Типичный код пишется на порядок проще. Сложный написать возможно
и тоже несложно. Примеры -- рядом, если любопытно.
И autoconf и, тем более, automake изначально имели отвратительный дизайн.
libtool -- единственное из этой тройки, что хоть как-то оправдано,
да и то с натяжкой.
И вообще, уважаемые коллеги.Ни одна система сборки не "должна собирать на любой системе".
Система сборки - это прежде всего язык, которым автор программы пользуется, чтобы описать, что он хочет для своей программы.
И autotools тут - великий и могучий язык.
Если забыть про макросы и Makefile.am, то autotools прекрасен уже тем, что позволяет прямо на месте спуститься на уровень shell и plain makefile, немедленно прямо в confugure.ac или Makefile.am. (примерно как php в html или наоборот.).
А если вы видели плохие пакеты с autotools, так это не проблема autotools, а тем программистов руками, которые их понаписали.
Тысячи их! https://twitter.com/i/#!/ip1981/media/slideshow?url=pic.twit...
Ю
> Если забыть про макросы и Makefile.am, то autotools прекрасен уже тем, что
> позволяет прямо на месте спуститься на уровень shell и plain makefile,Аааа, собственно, зачем мне еще слой m4, если 'спуститься на уровень shell' проще просто из make'а?
> Ю
>> Если забыть про макросы и Makefile.am, то autotools прекрасен уже тем, что
>> позволяет прямо на месте спуститься на уровень shell и plain makefile,
> Аааа, собственно, зачем мне еще слой m4, если 'спуститься на уровень shell'
> проще просто из make'а?Потому что вы плохо знаете shell и особенности различных операционных систем и реализация всевозможных функций, макросов, утилит?
Да и причёт тут m4? Это всего лишь язык, на котором написаны макросы. Или в cmake FindPackage() - дар божий?
>> Ю
>>> Если забыть про макросы и Makefile.am, то autotools прекрасен уже тем, что
>>> позволяет прямо на месте спуститься на уровень shell и plain makefile,
>> Аааа, собственно, зачем мне еще слой m4, если 'спуститься на уровень shell'
>> проще просто из make'а?
> Потому что вы плохо знаете shell и особенности различных операционных систем и
> реализация всевозможных функций, макросов, утилит?Из чего был сделан такой вывод?
> Да и причёт тут m4? Это всего лишь язык, на котором написаны
> макросы.Я не вижу, какую проблему мне решает наличие ещё одного слоя на m4.
Например, вполне сравнимый по мощности и возможносям язык макросов реализован в GNU Make Utility.> Или в cmake FindPackage() - дар божий?
Я этого не говорил. CMake лучше autotools только в одном: им можно пользоваться и на off-topic'е.
Уважаемый, вы в курсе, что ни m4, ни перл не нужны для сборки пакета, использующего autotools?configure - чистый shell, Makefile.in - чистый makefile (без GNU extentions, если разработчик не идиот). configure подставляет значения в Makefile.in. Всё.
> Уважаемый, вы в курсе, что ни m4, ни перл не нужны для
> сборки пакета, использующего autotools?
> configure - чистый shell, Makefile.in - чистый makefile (без GNU extentions, если
> разработчик не идиот). configure подставляет значения в Makefile.in. Всё.А, так Вы на уровне (./configure && make && sudo make install). На этом уровне все едино.
Вообще, система сборки нужна для более или менее серьёзного, многоплатформенного, пакета. Для поделок не нужен даже make - достаточно gcc *.c -o foo.
> Ю
>> Если забыть про макросы и Makefile.am, то autotools прекрасен уже тем, что
>> позволяет прямо на месте спуститься на уровень shell и plain makefile,
> Аааа, собственно, зачем мне еще слой m4, если 'спуститься на уровень shell'
> проще просто из make'а?Как бы это ни пафосно звучало, autotools предоставляет свободу и разработчику, и пользователю. Всегда можно сделать *нестандартную вешь*.
Перепишите на cmake/scons/gyp/wtf:(@<:@@:>@ == [], квадратные кавычки заняты autoconf)
AC_MSG_CHECKING([whether YAML::Node has operator@<:@@:>@ for char*])
save_CPPFLAGS="$CPPFLAGS"
CPPFLAGS="$YAMLCPP_CFLAGS"
AC_COMPILE_IFELSE([
AC_LANG_PROGRAM(
[#include <yaml.h>],
[YAML::Node doc; doc@<:@(char *)"test"@:>@;]
)],
[AC_MSG_RESULT([yes])
AC_DEFINE(YAML_NODE_HAS_OPERATOR_NONCONST_CHAR, [1], [Define if YAML::Node has operator@<:@@:>@ for char*])],
[AC_MSG_RESULT([no])]
)
CPPFLAGS="$save_CPPFLAGS"
> (@<:@@:>@ == [], квадратные кавычки заняты autoconf)
> И autotools тут - великий и могучий язык.зашибись какой великий и могучий. Настолько могучий, что к твоему примеру нужно в два раза больше коментов написать с объяснением что это такое и как оно работает.
только упоротый на всю голову autotools'ы может называть отличным инструментом.
вот ещё домашнее задание:https://github.com/ckolivas/cgminer/blob/master/m4/mmap-anon.m4
(перепишите на cmake/scons/gyp/wtf)
> вот ещё домашнее задание:
> https://github.com/ckolivas/cgminer/blob/master/m4/mmap-anon.m4
> (перепишите на cmake/scons/gyp/wtf)То же мне высшая магия. На mk-configure это делается
тривиально штатными средствами.
MKC_REQUIRE_HEADERS, MKC_REQUIRE_FUNCLIBS и MKC_CHECK_DEFINES.
Плюс стандартные средства bmake типа .if/.endif и CFLAGS += -D...
Ребята не надо меряться пиписьками. Тоже самое можно предложить и Вам: переписать CMake на Autotools.
На Cmake переходят не потому, что он такой хороший, а из-за обратной совместимости. Разработчику навряд ли захочется переписывать сборочные файлы (которые уже мхом поросли, и никто не помнит, что там вообще было) только потому, что ребята из GNU всталь не с той ноги.
Дело же не в переписывании, а том, как это реализовать на других системах сборки.
Правда в том, что не всегда всякие....вычурные фишки _нужно_ реализовывать в других системах сборки. KDE юзает cmake и счастлив, например. nginx юзает самописные чеки и не менее счастлив, V8 && MongoDB юзают scons и тоже счастливы.Лично мне не нравятся autotools-ы, хотя не могу сказать, что CMake столь уж прекрасен в написании - но там есть некоторая высокоуровневость и понятность :)
> Правда в том, что не всегда всякие....вычурные фишки _нужно_ реализовывать в других
> системах сборки. KDE юзает cmake и счастлив, например. nginx юзает самописные
> чеки и не менее счастлив, V8 && MongoDB юзают scons иV8 использует gyp, как и Node.js, и вот чем это кончается:
https://github.com/joyent/illumos-extra/commit/fc553cb0b9f36...
А сборка MongoDB - настоящий ад, особенно если компилятор типа такого /usr/gcc/4.4/bin/g++
> Правда в том, что не всегда всякие....вычурные фишки _нужно_ реализовывать в других
> системах сборки. KDE юзает cmake и счастлив, например. nginx юзает самописные
> чеки и не менее счастлив, V8 && MongoDB юзают scons и
> тоже счастливы.И не надо путать *нужно* и *возможно*. Не нужно - не делай. В том числе не пиши свою мега систему сборки.
Вот совету людей, собаку съевших, http://wiki.debian.org/UpstreamGuide
> Вот совету людей, собаку съевших, http://wiki.debian.org/UpstreamGuideНа Демьяне свет клином не сошёлся.
>> Вот совету людей, собаку съевших, http://wiki.debian.org/UpstreamGuide
> На Демьяне свет клином не сошёлся.Вот именно. Существует множество систем, компиляторов, компоновщиков, библиотек, структур файловых систем и проч. А GNU, в силу отсутствия собственной ОС, имеют систему сборки Autotool, которая и делает GNU страшно портируемой.
>>> Вот совету людей, собаку съевших, http://wiki.debian.org/UpstreamGuide
>> На Демьяне свет клином не сошёлся.
> Вот именно. Существует множество систем, компиляторов,
> компоновщиков, библиотек, структур
> файловых систем и проч. А GNU, в силу отсутствия собственной ОС,
> имеют систему сборки Autotool, которая и делает GNU страшно портируемой.Страшно дерьмовой он ее делает. Надо людям-осиляторам ознакомиться
все-таки с альтернативными подходами, тогда мир станет
больше, красивее и разнообразнее ;-)