The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Релиз генератора файлов сборки GNU Automake 1.16

26.02.2018 21:11

Доступен релиз Automake 1.16, утилиты для автоматической генерации 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 в плане корректной обработки ситуации вызова без аргументов при указании опции "-f" (запуск "rm -f" без имени файла не должен завершаться ошибкой).

  1. Главная ссылка к новости (https://www.mail-archive.com/i...)
  2. OpenNews: Выпуск генератора файлов сборки GNU Automake 1.15.1
  3. OpenNews: Выпуск генератора файлов сборки GNU Automake 1.15
  4. OpenNews: Вышел GNU Autoconf 2.65, теперь под лицензией GPLv3
  5. OpenNews: Релиз GNU autoconf 2.69
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/48150-automake
Ключевые слова: automake
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (37) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Ne01eX (ok), 22:43, 26/02/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >>Будет прекращена поддержка имени 'configure.in' в качестве входного файла для Autoconf

    И вроде бы давно пора. Для своих поделок я configure.ac давно использую. Но вот скрипты сборки других разработчиков придётся перепиливать. И этого ПО много... :-\ Ладно, не смертельно, переживём и это...

     
  • 1.2, нах (?), 22:47, 26/02/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    а они стараааательные. В смысле, очень стараются добиться того, чтобы последние ретрограды еще не свалившие на cmake или вовсе на meson, валили поскорей.
     
     
  • 2.29, X4asd (ok), 14:58, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > а они стараааательные. В смысле, очень стараются добиться того, чтобы последние ретрограды еще не свалившие на cmake или вовсе на meson, валили поскорей.

    скорее стараются чтобы хоть кто-то кроме ретограда -- сделал бы хотябы один новый проект с использованием automake. :-)

    количество ретроградов которые через 5 дней не собираются уехать в окончательный пенсионный отдых -- стремительно приближатся к 0..

    ...так что особо ориентироваться на них не стоит

     

  • 1.4, anonymous yet another (?), 23:20, 26/02/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    А что, autotools на W... действительно для кого-то представляют интерес?
     
     
  • 2.9, CAE (?), 11:07, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А альтернатива? mk-configure неплохая идея, но пока маловато по сравнению с autotools. CMake - язык учить, yet another. Scons?
     
     
  • 3.12, Аноним (-), 13:04, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >  CMake - язык учить

    лучше язык, чем неизданный справочник костылей и грабель: http://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/

    cmake кстати не идеален, но сложившая практика использования cmake новых версий приводит к хорошему результату: получается достаточно декларативный скрипт, позволяющий геренировать сборки для мультиплатформ, среди которых актуальные, но неподдерживаемые autotools-ами

     
     
  • 4.13, Ne01eX (ok), 13:22, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    >>  CMake - язык учить
    > лучше язык, чем неизданный справочник костылей и грабель: http://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/
    > cmake кстати не идеален, но сложившая практика использования cmake новых версий приводит
    > к хорошему результату: получается достаточно декларативный скрипт, позволяющий геренировать
    > сборки для мультиплатформ, среди которых актуальные, но неподдерживаемые autotools-ами

    Ребя, я щас на полном серЪёзе. Я тут книгу пописываю по тихой сапе про использование gnu make / autoconf+automake / CMake в своих проектах. В равной степени. Потому что считаю, что существующая документация написана какими-то инопланетянами. Это порождает кучу недопонимания, мифов и предубеждений.

    Может, в натуре, краудфандинг какой-нибудь организовать? А то я смотрю, многие не совсем догоняют что есть что и как это использовать (в том числе и jussi.pakkanen :-) )...

    Есть желающие помочь деньгами?

     
     
  • 5.14, пох (?), 13:26, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • –4 +/
    мне кажется, вы зря тратите время. Это не прочтут, а пока будут читать, оно устареет.
    Пишите книгу про meson.

     
     
  • 6.16, Ne01eX (ok), 13:30, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > мне кажется, вы зря тратите время. Это не прочтут, а пока будут
    > читать, оно устареет.
    > Пишите книгу про meson.

    meson тоже можно упомянуть, но главная цель - поддержка проектов GNU. А это как раз make / autoconf + automake. CMake идёт прицепом, как альтернатива.

     
     
  • 7.17, пох (?), 13:54, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > meson тоже можно упомянуть, но главная цель - поддержка проектов GNU

    а смысл? Это ж либо склад раритетов, либо (то немногое что живо вопреки GNU) - перепишут на meson, или еще какую модную ненужно.

    В любом случае, чтобы "поддерживать", разбираться в этом необязательно.
    Чтобы сделать что-то свое - желательно, но никто не хочет.
    Поэтому рождаются бесполезные и бессмысленные монстры, проверяющие миллион ненужных параметров, при том что программа кое-как собирается и работает только в одной-единственной их комбинации.

    До сих пор вспоминаю с истерическим смехом свою первую (и, надеюсь, последнюю) встречу с mono, только-только выпущенным в свет. Оно требовало два десятка километровой длины environment variables, потом каким-то нетривиальным способом надо было с ними запустить configure, которая работала минут пять, после чего радостно сообщала, что твоя система не linux и не забыл что еще (какая-то экзотика, чуть ли не hpux) поэтому напиши тут быстренько свою версию вот этих 500 килобайтных исходников (видимо, какой-то middleware) и потом приходи.

    Спрашивается - ребята, а зачем вам вообще был при этом autoconf-то нужен? А мы не знаем, так принято. Причем как именно принято - мы тоже не разобрались второпях, поэтому слепили как получилось.

     
     
  • 8.20, Аноним (-), 14:00, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вот поэтому нужна внятная книга - учитель в виде книги который обучает в каком н... текст свёрнут, показать
     
     
  • 9.22, пох (?), 14:05, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    да не будут они ее читать, грант уйдет я вроде понял, но автор книги уточнил чт... текст свёрнут, показать
     
     
  • 10.23, Аноним (-), 14:13, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не знаю как вы себе позволяете, но я не могу говорить за других Я скажу за себя... текст свёрнут, показать
     
     
  • 11.25, пох (?), 14:30, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    стесняюсь спросить - вы читать-то ту что есть - пробовали Ну вот просто info au... текст свёрнут, показать
     
     
  • 12.27, Аноним (-), 14:38, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    На info automake мне надо тратить больше время чем мне хочется, так как нужно ра... текст свёрнут, показать
     
  • 10.36, yet another anonymous (?), 12:05, 28/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Надеюсь что нет meson --- такой же монстр Там python --- т е все питоньи проб... текст свёрнут, показать
     
  • 7.18, Аноним (-), 13:56, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > meson тоже можно упомянуть, но главная цель - поддержка проектов GNU. А это как раз make / autoconf + automake. CMake идёт прицепом, как альтернатива.

    Поддержка проектов GNU - дело хорошее, вас могут поддержать в том числе и фанаты GNU. CMake, meson, etc - это из серии "пришел-ушел", то есть сегодня одно, завтра - другое.
    Советую вам заявить о себе чтобы вас увидела целевая аудитория так чтобы можно видеть хотя бы статус проекта (можете публиковать оглавление и отмечать какие главы уже написаны, а какие в процессе). Мне интересна ваша работа с разных точек зрения, поэтому хотелось бы видеть как продвигаются и обстоят дела. Но обещать я ничего не могу.

     
  • 7.28, CAE (?), 14:44, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    IMHO если уж брать что-то с чисто декларативным стилем, то mk-configure. Но автор не имеет кучи ресурсов, да и проект слабоизвестный. Но задумка опереться на bsd-style mk - очень здравая, кто под фрёй порты смотрел, тот поймёт о чём я. И язык уже наполовину известен по makefile.
     
  • 6.34, Аноним (-), 22:56, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > пока будут читать, оно устареет.
    > Пишите книгу про meson.

    meson устареет ещё до того, как он эту книгу закончит

     
  • 5.30, Аноним (-), 15:21, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Я тут книгу пописываю по тихой сапе про использование gnu make / autoconf+automake / CMake в своих проектах. В равной степени. Потому что считаю, что существующая документация написана какими-то инопланетянами.

    У GNU make и cmake очень хорошая документация. А autoconf и automake сами написаны инополанетянами, так что их ни документация, ни книги никакие не спасут.

     
  • 4.24, CAE (?), 14:18, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >>  CMake - язык учить
    > лучше язык, чем неизданный справочник костылей и грабель: http://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/

    Статья отличная. У самого полно проблем с простейшим повторным запуском одного макроса :) И где документировано, что для второго запуска его лучше обернуть в shell function - бог весть. Autotools - адище, только старый опыт с sendmail+m4 и позволяет как-то жить.

     
     
  • 5.26, пох (?), 14:34, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > в shell function - бог весть. Autotools - адище, только старый
    > опыт с sendmail+m4 и позволяет как-то жить.

    ну вот по-моему выучить относительно универсальный (пусть и нигде нынче неиспользуемый) m4 (хотя бы на уровне правил расстановки кавычек) и запомнить где посмотреть два десятка макросов - гораздо правильней, чем учить мертворожденный язык cmake.

    но это если вообще есть зачем его учить. Я в этом последнее время сильно не уверен.

     
     
  • 6.31, Аноним (-), 15:57, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > учить мертворожденный язык cmake

    Иди проспись. Такой мертворожденности только позавидовать. А учить там особо и нечего, сам язык исключительно примитивен (в отличие от набора команд и переменных, но с ними всё же многократно приятнее иметь дело, чем с макросами автокрэпа).

     
  • 6.37, yet another anonymous (?), 12:15, 28/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> в shell function - бог весть. Autotools - адище, только старый
    >> опыт с sendmail+m4 и позволяет как-то жить.
    > ну вот по-моему выучить относительно универсальный (пусть и нигде нынче неиспользуемый)
    > m4 (хотя бы на уровне правил расстановки кавычек) и запомнить где
    > посмотреть два десятка макросов - гораздо правильней, чем учить мертворожденный язык
    > cmake.

    В autotools проблема ни разу не в m4. Разбирать макросы в том объёме --- малопродуктивное занятие. А набор/поведение макросов меняется в каждой версии autocraps. В чём цель-то была?

    > но это если вообще есть зачем его учить. Я в этом последнее
    > время сильно не уверен.

     
  • 3.40, Аноним (-), 15:17, 28/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > CMake - язык учить, yet another

    Это глупейшая претензия, так как у каждой уважающей утилиты есть свой язык в том или ином виде, начиная с конфига. Потому что язык заточенный под конкретную цель всегда лаконичнее и удобнее чем что-то-общего-назначения. А так у cmake простой и чистый синтаксис.

    > Scons?

    Даже близко не подходи. Это даже не система сборки, это фреймворк чуть-чуть помогающий в написании системы сборки, в результате которого появляется монструозные скрипты на питоне сравнимые по нечитабельности с configure, причём вместо унификации каждый из них велосипедит свой способ обработки аргументов, флагов, поиска зависимостей и т.д. Ещё и с переходом на 3 питон будут проблемы.

     

  • 1.6, Аноним (-), 00:12, 27/02/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Ну зачем они это делают?
     
     
  • 2.7, Led (ok), 01:18, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ну зачем они это делают?

    Чтоб у хипстеров подгорало.

     
  • 2.8, пох (?), 09:52, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ну такие вот нынче пошли "разработчики". Другие вымерли или подались в эффективные менеджеры.

    завязать пакет утилит для разработки _переносимых_ программ исключительно на gnu rm - как мило...

    Впрочем, предлагаю расслабиться. Последней попадавшей мне под руку программой, использующей configure по назначению, был php5. (он же - и работает в том числе на крайне экзотических системах)
    Умение писать не linux-only программы утрачено обезьянками напрочь, если современный софт и собирается под чем-то другим, то потому, что авторы чего-то другого потратили неимоверные усилия на багосовместимость именно с линуксом. autoconf сто лет уже как всеми используется не для переносимости, а потому, что умение написать собственный шелл-скрипт с аж пятью возможными опциями конфигурации - тоже утрачено нафиг, как и умение писать мэйкфайлы.

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

    Поэтому безумный миллион autoconf'овых проверок жрет ресурсы планеты совершенно зря - результат все равно способен работать только на одной-единственной платформе.

     
     
  • 3.11, user (??), 12:26, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >рассчитаны на использование утилиты "rm", соответствующей требованиям следующей версии стандарта POSIX
    >завязать пакет утилит для разработки _переносимых_ программ исключительно на gnu rm

    У кого-то проблемы со зрением.

     
     
  • 4.19, пох (?), 14:00, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>рассчитаны на использование утилиты "rm", соответствующей требованиям следующей версии стандарта POSIX
    >>завязать пакет утилит для разработки _переносимых_ программ исключительно на gnu rm
    > У кого-то проблемы со зрением.

    у кого-то проблемы с пониманием. Требование соответствия еще недонаписанному стандарту POSIX, на которые все давно уже наплевали, это просто завуалированное "мы ничего кроме линуксных fileutils ниасилили и асиливать не хотим, такой у нас афигенный автоматический генератор *портабильного* кода". С линукса на линукс, и только наираспоследней версии, обпортируйтесь.

    это ж гораздо проще, чем головой думать.


     
     
  • 5.32, Аноним (-), 16:00, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > у кого-то проблемы с пониманием. Требование соответствия еще недонаписанному стандарту
    > POSIX, на которые все давно уже наплевали, это просто завуалированное "мы
    > ничего кроме линуксных fileutils ниасилили и асиливать не хотим, такой у
    > нас афигенный автоматический генератор *портабильного* кода".

    Ты давно видел какую-нибудь реализацию rm, которая с опцией -f возвращает статус, отличный от 0? Скажи, где такую найти, мне интересно посмотреть.

     
     
  • 6.33, пох (?), 18:08, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ты давно видел какую-нибудь реализацию rm, которая с опцией -f возвращает статус, отличный от 0?

    довольно давно, но уверен, она там вполне себе и осталась, лежит себе в bin ;-) (хепе, да. Оно еще и -rf / умело, не то что нынешние)

    А вот та, которая 0, полагаю, наличествует ровно в линуксе и *bsd (где вынуждены копировать все причуды). Даже за современную солярку не вполне уверен.

    А теперь возвращаемся к исходному вопросу: зачем вам сложная и не очень современная система автоматического учета особенностей платформы, если она работает только на линуксе и еще шаг-полтора в сторону, где именно линукс и вынуждены копировать, даже если не хотят?

    Если вы хотите этим признать, что кроме линуксов разного сорта и их эмуляций ничего и не осталось - ок, а система-то тогда - зачем?

     
  • 5.39, yet another anonymous (?), 13:37, 28/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > "мы
    > ничего кроме линуксных fileutils ниасилили и асиливать не хотим, такой у
    > нас афигенный автоматический генератор *портабильного* кода". С линукса на линукс, и
    > только наираспоследней версии, обпортируйтесь.

    Автоматический генератор *портабельного кода*, говорите? Ну-ну. McNealy что-то уже приносил с похожими словами.

     
  • 3.38, yet another anonymous (?), 13:29, 28/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Поэтому безумный миллион autoconf'овых проверок жрет ресурсы планеты совершенно зря - результат все равно способен работать только на одной-единственной платформе.

    Это таки да, но в этом оно мало отличается и от CMake/SCons/meson.

    О вариациях для разных платформ все равно должен заботиться автор, а проверки на тему HAVE_UNISTD_H практически бессмысленны.

     

  • 1.10, Аноним (-), 11:23, 27/02/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    С удалением поддержки DOS они погорячились, ведь есть же FreeDOS и он жив.
     
     
  • 2.15, Ne01eX (ok), 13:26, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > С удалением поддержки DOS они погорячились, ведь есть же FreeDOS и он
    > жив.

    FreDOS не использует automake

     
  • 2.21, пох (?), 14:01, 27/02/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > С удалением поддержки DOS они погорячились, ведь есть же FreeDOS и он
    > жив.

    и много вы знаете проектов программ под freedos, использующих autoconf? А _новых_, которым вот уперлось использовать самую последнюю версию?

    imho, под windows ME их и то могло бы быть больше (в смысле, чисто по недоразумению, что-нибудь еще не только собирается, но и работает)


     

  • 1.35, Аноним (-), 03:30, 28/02/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вообще это гонение в системах сборки достало уже.
    Так было хорошо, что тут не нужен был питон.
    Но нет начали всобачивать meson с нинзей.
    Ну ладно бы как опция, но на "некоторых" проектах это стало безальтернативно.
    С относительно недавних пор на своих проектах начал вплотную использовать чистый Makefile без всяких генерилок. Работать стало приятнее, не надо думать что опять кто-нибудь где-нибудь что-то сломает. Вначале нужно немного больше подумать о том как собирать проект, но оно того стоит. Значительное время использовал cmake. Но то как редхатовцы его последнее время его заворачивают и как он (cmake) генерирует маны заставило меня задуматься нужен ли он мне вообще?!

    А так для более сложных вещей automake и autoconf самое то.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру