Доступен (https://www.mail-archive.com/info-gnu@gnu.org/msg02414....) релиз Automake 1.16 (http://www.gnu.org/software/automake/), утилиты для автоматической генерации make-файлов, соответствующих стандартам кодирования проекта GNU. В новой версии в "contrib" добавлен тестовый набор для API Guile Scheme SRFI-64. Решены проблемы с отслеживанием зависимостей при использовании опции 'subdir-object'. Кроме того, при использовании subdir-object Automake теперь создаёт короткие имена объектов, если не наблюдается пересечений имён программ и библиотек.
В примечании к выпуску также включено уведомление о ряде нарушений совместимости в будущей ветке Automake 2.0. Работа Automake 2.0 будет возможна только вкупе с пакетом Autoconf 2.70+. Будет прекращена поддержка имени 'configure.in' в качестве входного файла для Autoconf, скрипты будут рассчитаны на работу с POSIX shell, все внешние m4-файлы (в директориях $ACLOCAL_PATH и aclocal) будут иметь более высокий приоритет по сравнению со встроенными макросами. Будет удалена поддержка MS-DOS и Windows 95/98/ME. Генерируемые сценарии рассчитаны на использование утилиты "rm", соответствующей требованиям следующей версии стандарта POSIX в плане корректной обработки ситуации (http://austingroupbugs.net/view.php?id=542) вызова без аргументов при указании опции "-f" (запуск "rm -f" без имени файла не должен завершаться ошибкой).URL: https://www.mail-archive.com/info-gnu@gnu.org/msg02414....
Новость: https://www.opennet.ru/opennews/art.shtml?num=48150
>>Будет прекращена поддержка имени 'configure.in' в качестве входного файла для AutoconfИ вроде бы давно пора. Для своих поделок я configure.ac давно использую. Но вот скрипты сборки других разработчиков придётся перепиливать. И этого ПО много... :-\ Ладно, не смертельно, переживём и это...
а они стараааательные. В смысле, очень стараются добиться того, чтобы последние ретрограды еще не свалившие на cmake или вовсе на meson, валили поскорей.
> а они стараааательные. В смысле, очень стараются добиться того, чтобы последние ретрограды еще не свалившие на cmake или вовсе на meson, валили поскорей.скорее стараются чтобы хоть кто-то кроме ретограда -- сделал бы хотябы один новый проект с использованием automake. :-)
количество ретроградов которые через 5 дней не собираются уехать в окончательный пенсионный отдых -- стремительно приближатся к 0..
...так что особо ориентироваться на них не стоит
А что, autotools на W... действительно для кого-то представляют интерес?
А альтернатива? mk-configure неплохая идея, но пока маловато по сравнению с autotools. CMake - язык учить, yet another. Scons?
> CMake - язык учитьлучше язык, чем неизданный справочник костылей и грабель: http://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/
cmake кстати не идеален, но сложившая практика использования cmake новых версий приводит к хорошему результату: получается достаточно декларативный скрипт, позволяющий геренировать сборки для мультиплатформ, среди которых актуальные, но неподдерживаемые autotools-ами
>> CMake - язык учить
> лучше язык, чем неизданный справочник костылей и грабель: http://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/
> cmake кстати не идеален, но сложившая практика использования cmake новых версий приводит
> к хорошему результату: получается достаточно декларативный скрипт, позволяющий геренировать
> сборки для мультиплатформ, среди которых актуальные, но неподдерживаемые autotools-амиРебя, я щас на полном серЪёзе. Я тут книгу пописываю по тихой сапе про использование gnu make / autoconf+automake / CMake в своих проектах. В равной степени. Потому что считаю, что существующая документация написана какими-то инопланетянами. Это порождает кучу недопонимания, мифов и предубеждений.
Может, в натуре, краудфандинг какой-нибудь организовать? А то я смотрю, многие не совсем догоняют что есть что и как это использовать (в том числе и jussi.pakkanen :-) )...
Есть желающие помочь деньгами?
мне кажется, вы зря тратите время. Это не прочтут, а пока будут читать, оно устареет.
Пишите книгу про meson.
> мне кажется, вы зря тратите время. Это не прочтут, а пока будут
> читать, оно устареет.
> Пишите книгу про meson.meson тоже можно упомянуть, но главная цель - поддержка проектов GNU. А это как раз make / autoconf + automake. CMake идёт прицепом, как альтернатива.
> meson тоже можно упомянуть, но главная цель - поддержка проектов GNUа смысл? Это ж либо склад раритетов, либо (то немногое что живо вопреки GNU) - перепишут на meson, или еще какую модную ненужно.
В любом случае, чтобы "поддерживать", разбираться в этом необязательно.
Чтобы сделать что-то свое - желательно, но никто не хочет.
Поэтому рождаются бесполезные и бессмысленные монстры, проверяющие миллион ненужных параметров, при том что программа кое-как собирается и работает только в одной-единственной их комбинации.До сих пор вспоминаю с истерическим смехом свою первую (и, надеюсь, последнюю) встречу с mono, только-только выпущенным в свет. Оно требовало два десятка километровой длины environment variables, потом каким-то нетривиальным способом надо было с ними запустить configure, которая работала минут пять, после чего радостно сообщала, что твоя система не linux и не забыл что еще (какая-то экзотика, чуть ли не hpux) поэтому напиши тут быстренько свою версию вот этих 500 килобайтных исходников (видимо, какой-то middleware) и потом приходи.
Спрашивается - ребята, а зачем вам вообще был при этом autoconf-то нужен? А мы не знаем, так принято. Причем как именно принято - мы тоже не разобрались второпях, поэтому слепили как получилось.
> Спрашивается - ребята, а зачем вам вообще был при этом autoconf-то нужен? А мы не знаем, так принято. Причем как именно принято - мы тоже не разобрались второпях, поэтому слепили как получилось.Вот поэтому нужна внятная книга - учитель в виде книги который обучает в каком направлении двигаться. Очень странно что вы сами непоняли из содержания своего сообщения суть проблемы и почему нужна книга.
> Вот поэтому нужна внятная книга - учитель в виде книги который обучаетда не будут они ее читать, грант уйдет.
> в каком направлении двигаться. Очень странно что вы сами непоняли из
> содержания своего сообщения суть проблемы и почему нужна книга.я вроде понял, но автор книги уточнил что ему оно "в первую очередь для поддержки проектов GNU". А это либо окаменелости, либо завтра перепишут на meson, а послезавтра на npm.
Нет, ну вперед на boomstarter, прецеденты были.
> да не будут они ее читать, грант уйдет.Не знаю как вы себе позволяете, но я не могу говорить за других. Я скажу за себя: я не разбираюсь с autoconf+automake только потому что нет основательной и внятной документации. Я точно уверен что мне надо потратить достаточно много времени чтобы разобраться на должном уровне. Была бы хорошая книга (не сухое бессвязное руководство) - я бы точно поразбирался, например почитывая главы вечерком после работы.
Я точно уверен что книга нужна. Причем нужна электронная и с поддержкой актуализации. Соответственно, спонсирование деятельности автора тоже должна быть по результату актуализации.
> Я скажу за себя: я не разбираюсь с autoconf+automake только потому что нет основательной и
> внятной документациистесняюсь спросить - вы читать-то ту что есть - пробовали?
Ну вот просто info automake ?Не сказать, что она прямо замечательная, и ее точно не хочется читать главами после работы, да и не нужно - нужно брать и _делать_, подглядывя в методичку, какие именно слова и в каком порядке говорить. Бреда mono-style у вас при этом не выйдет, даже если будете стараться.
В какой-то момент придется плюнуть и посмотреть в исходники - они тоже не сказать чтоб нечитаемы, во всяком случае, когда лезешь туда за пониманием механизмов, а не ради что-то исправить.А книжка отложенная на почитать когда-нибудь потом...ну будет почитаема когда-нибудь потом. А проект мы наляпаем на том, что попало под руку и скопировали готовый скрипт откуда-то еще.
Проблема в другом - на самом деле пользы от этого набора скриптов не так много, как требуется времени, чтобы в нем как следует разобраться. Потому что код за вас он писать не будет, а примитивный генератор config.h на ровно две поддерживаемых конфигурации можно без особых сложностей написать самому (сэкономив планете кучу ресурсов на миллиардах ненужных проверок).
А про make вам книжку написали Керниган и Пайк в 89м году, чтобы понять что там наворотили в gnu версии - опять же достаточно бегло глянуть info (хорошо бы остановиться потом и подумать, только ли на линуксе твой шадевр будут собирать - а то может и не стоит).
>стесняюсь спросить - вы читать-то ту что есть - пробовали?
>Ну вот просто info automake ?
>Не сказать, что она прямо замечательная, и ее точно не хочется читать главами после работы, да и не нужно - нужно брать и _делать_, подглядывя в методичку, какие именно слова и в каком порядке говорить. Бреда mono-style у вас при этом не выйдет, даже если будете стараться.
>В какой-то момент придется плюнуть и посмотреть в исходники - они тоже не сказать чтоб нечитаемы, во всяком случае, когда лезешь туда за пониманием механизмов, а не ради что-то исправить.На info automake мне надо тратить больше время чем мне хочется, так как нужно разбираться. А вечером после работы я разбираться не сильно хочу, т.к. целый день только и делаю что разбираюсь. почитал бы то что в голову легко влезет.
>А про make вам книжку написали Керниган и Пайк в 89м году, чтобы понять что там наворотили в gnu версии - опять же достаточно бегло глянуть info (хорошо бы остановиться потом и подумать, только ли на линуксе твой шадевр будут собирать - а то может и не стоит).
С make я разобрался основательно и уже давно, причем без книг. Может конечно что-то новое добавилось, но пока я ничего нового не встречал.
> А это либо окаменелости, либо завтра перепишут на meson, ...Надеюсь что нет. meson --- такой же монстр. Там python --- т.е. все питоньи проблемы подтягиваются.
> meson тоже можно упомянуть, но главная цель - поддержка проектов GNU. А это как раз make / autoconf + automake. CMake идёт прицепом, как альтернатива.Поддержка проектов GNU - дело хорошее, вас могут поддержать в том числе и фанаты GNU. CMake, meson, etc - это из серии "пришел-ушел", то есть сегодня одно, завтра - другое.
Советую вам заявить о себе чтобы вас увидела целевая аудитория так чтобы можно видеть хотя бы статус проекта (можете публиковать оглавление и отмечать какие главы уже написаны, а какие в процессе). Мне интересна ваша работа с разных точек зрения, поэтому хотелось бы видеть как продвигаются и обстоят дела. Но обещать я ничего не могу.
IMHO если уж брать что-то с чисто декларативным стилем, то mk-configure. Но автор не имеет кучи ресурсов, да и проект слабоизвестный. Но задумка опереться на bsd-style mk - очень здравая, кто под фрёй порты смотрел, тот поймёт о чём я. И язык уже наполовину известен по makefile.
> пока будут читать, оно устареет.
> Пишите книгу про meson.meson устареет ещё до того, как он эту книгу закончит
> Я тут книгу пописываю по тихой сапе про использование gnu make / autoconf+automake / CMake в своих проектах. В равной степени. Потому что считаю, что существующая документация написана какими-то инопланетянами.У GNU make и cmake очень хорошая документация. А autoconf и automake сами написаны инополанетянами, так что их ни документация, ни книги никакие не спасут.
>> CMake - язык учить
> лучше язык, чем неизданный справочник костылей и грабель: http://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/Статья отличная. У самого полно проблем с простейшим повторным запуском одного макроса :) И где документировано, что для второго запуска его лучше обернуть в shell function - бог весть. Autotools - адище, только старый опыт с sendmail+m4 и позволяет как-то жить.
> в shell function - бог весть. Autotools - адище, только старый
> опыт с sendmail+m4 и позволяет как-то жить.ну вот по-моему выучить относительно универсальный (пусть и нигде нынче неиспользуемый) m4 (хотя бы на уровне правил расстановки кавычек) и запомнить где посмотреть два десятка макросов - гораздо правильней, чем учить мертворожденный язык cmake.
но это если вообще есть зачем его учить. Я в этом последнее время сильно не уверен.
> учить мертворожденный язык cmakeИди проспись. Такой мертворожденности только позавидовать. А учить там особо и нечего, сам язык исключительно примитивен (в отличие от набора команд и переменных, но с ними всё же многократно приятнее иметь дело, чем с макросами автокрэпа).
>> в shell function - бог весть. Autotools - адище, только старый
>> опыт с sendmail+m4 и позволяет как-то жить.
> ну вот по-моему выучить относительно универсальный (пусть и нигде нынче неиспользуемый)
> m4 (хотя бы на уровне правил расстановки кавычек) и запомнить где
> посмотреть два десятка макросов - гораздо правильней, чем учить мертворожденный язык
> cmake.В autotools проблема ни разу не в m4. Разбирать макросы в том объёме --- малопродуктивное занятие. А набор/поведение макросов меняется в каждой версии autocraps. В чём цель-то была?
> но это если вообще есть зачем его учить. Я в этом последнее
> время сильно не уверен.
> CMake - язык учить, yet anotherЭто глупейшая претензия, так как у каждой уважающей утилиты есть свой язык в том или ином виде, начиная с конфига. Потому что язык заточенный под конкретную цель всегда лаконичнее и удобнее чем что-то-общего-назначения. А так у cmake простой и чистый синтаксис.
> Scons?
Даже близко не подходи. Это даже не система сборки, это фреймворк чуть-чуть помогающий в написании системы сборки, в результате которого появляется монструозные скрипты на питоне сравнимые по нечитабельности с configure, причём вместо унификации каждый из них велосипедит свой способ обработки аргументов, флагов, поиска зависимостей и т.д. Ещё и с переходом на 3 питон будут проблемы.
Ну зачем они это делают?
> Ну зачем они это делают?Чтоб у хипстеров подгорало.
ну такие вот нынче пошли "разработчики". Другие вымерли или подались в эффективные менеджеры.завязать пакет утилит для разработки _переносимых_ программ исключительно на gnu rm - как мило...
Впрочем, предлагаю расслабиться. Последней попадавшей мне под руку программой, использующей configure по назначению, был php5. (он же - и работает в том числе на крайне экзотических системах)
Умение писать не linux-only программы утрачено обезьянками напрочь, если современный софт и собирается под чем-то другим, то потому, что авторы чего-то другого потратили неимоверные усилия на багосовместимость именно с линуксом. autoconf сто лет уже как всеми используется не для переносимости, а потому, что умение написать собственный шелл-скрипт с аж пятью возможными опциями конфигурации - тоже утрачено нафиг, как и умение писать мэйкфайлы.А если, не дай Б-же, кто-то пишет, то получается ад, трэш и п-ц, как у мозилы, требующей стопиццот питоновских модулей и сэндбоксинга, а потом...тадам, запускающей все тот же configure, потому что разобраться, как оно работало до них, тоже ниасилили.
Поэтому безумный миллион autoconf'овых проверок жрет ресурсы планеты совершенно зря - результат все равно способен работать только на одной-единственной платформе.
>рассчитаны на использование утилиты "rm", соответствующей требованиям следующей версии стандарта POSIX
>завязать пакет утилит для разработки _переносимых_ программ исключительно на gnu rmУ кого-то проблемы со зрением.
>>рассчитаны на использование утилиты "rm", соответствующей требованиям следующей версии стандарта POSIX
>>завязать пакет утилит для разработки _переносимых_ программ исключительно на gnu rm
> У кого-то проблемы со зрением.у кого-то проблемы с пониманием. Требование соответствия еще недонаписанному стандарту POSIX, на которые все давно уже наплевали, это просто завуалированное "мы ничего кроме линуксных fileutils ниасилили и асиливать не хотим, такой у нас афигенный автоматический генератор *портабильного* кода". С линукса на линукс, и только наираспоследней версии, обпортируйтесь.
это ж гораздо проще, чем головой думать.
> у кого-то проблемы с пониманием. Требование соответствия еще недонаписанному стандарту
> POSIX, на которые все давно уже наплевали, это просто завуалированное "мы
> ничего кроме линуксных fileutils ниасилили и асиливать не хотим, такой у
> нас афигенный автоматический генератор *портабильного* кода".Ты давно видел какую-нибудь реализацию rm, которая с опцией -f возвращает статус, отличный от 0? Скажи, где такую найти, мне интересно посмотреть.
> Ты давно видел какую-нибудь реализацию rm, которая с опцией -f возвращает статус, отличный от 0?довольно давно, но уверен, она там вполне себе и осталась, лежит себе в bin ;-) (хепе, да. Оно еще и -rf / умело, не то что нынешние)
А вот та, которая 0, полагаю, наличествует ровно в линуксе и *bsd (где вынуждены копировать все причуды). Даже за современную солярку не вполне уверен.
А теперь возвращаемся к исходному вопросу: зачем вам сложная и не очень современная система автоматического учета особенностей платформы, если она работает только на линуксе и еще шаг-полтора в сторону, где именно линукс и вынуждены копировать, даже если не хотят?
Если вы хотите этим признать, что кроме линуксов разного сорта и их эмуляций ничего и не осталось - ок, а система-то тогда - зачем?
> "мы
> ничего кроме линуксных fileutils ниасилили и асиливать не хотим, такой у
> нас афигенный автоматический генератор *портабильного* кода". С линукса на линукс, и
> только наираспоследней версии, обпортируйтесь.Автоматический генератор *портабельного кода*, говорите? Ну-ну. McNealy что-то уже приносил с похожими словами.
> Поэтому безумный миллион autoconf'овых проверок жрет ресурсы планеты совершенно зря - результат все равно способен работать только на одной-единственной платформе.Это таки да, но в этом оно мало отличается и от CMake/SCons/meson.
О вариациях для разных платформ все равно должен заботиться автор, а проверки на тему HAVE_UNISTD_H практически бессмысленны.
С удалением поддержки DOS они погорячились, ведь есть же FreeDOS и он жив.
> С удалением поддержки DOS они погорячились, ведь есть же FreeDOS и он
> жив.FreDOS не использует automake
> С удалением поддержки DOS они погорячились, ведь есть же FreeDOS и он
> жив.и много вы знаете проектов программ под freedos, использующих autoconf? А _новых_, которым вот уперлось использовать самую последнюю версию?
imho, под windows ME их и то могло бы быть больше (в смысле, чисто по недоразумению, что-нибудь еще не только собирается, но и работает)
Вообще это гонение в системах сборки достало уже.
Так было хорошо, что тут не нужен был питон.
Но нет начали всобачивать meson с нинзей.
Ну ладно бы как опция, но на "некоторых" проектах это стало безальтернативно.
С относительно недавних пор на своих проектах начал вплотную использовать чистый Makefile без всяких генерилок. Работать стало приятнее, не надо думать что опять кто-нибудь где-нибудь что-то сломает. Вначале нужно немного больше подумать о том как собирать проект, но оно того стоит. Значительное время использовал cmake. Но то как редхатовцы его последнее время его заворачивают и как он (cmake) генерирует маны заставило меня задуматься нужен ли он мне вообще?!А так для более сложных вещей automake и autoconf самое то.