The OpenNET Project / Index page

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

Доступен GNU Autoconf 2.69b для тестирования изменений, потенциально нарушающих совместимость

15.07.2020 11:25

После восьми лет с момента публикации версии 2.69 представлен выпуск пакета GNU Autoconf 2.69b, в котором поставляется набор M4-макросов для создания скриптов автоконфигурации для сборки приложений в различных Unix-подобных системах (на основе подготовленного шаблона выполняется генерация скрипта "configure"). Выпуск позиционируется как бета-версия будущей версии 2.70.

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

Среди изменений:

  • Обеспечено экранирование аргументов config.log в заголовочном комментарии. Улучшена читаемость вывода "config.status --config";
  • В скрипт configure добавлена опция '--runstatedir' для определения пути к каталогу /run с pid-файлами;
  • В autoreconf прекращена поддержка версий automake и aclocal, выпущенных раньше 1.8;
  • Рекомендовано использовать printf вместо echo, макросы AS_ECHO и AS_ECHO_N теперь преобразуются в 'printf "%s\n"' и 'printf %s'. Переведены в разряд устаревших недокументированные переменные $as_echo и $as_echo_n, вместо которых следует использовать макросы AS_ECHO и AS_ECHO_N;
  • Многие макросы изменены для раскрытия аргументов только один раз для ускорения выполнения autoconf, что может сказаться на совместимости с некоторыми скриптами, не выполняющими корректных квотинг аргументов;
  • Некоторые макросы, такие как AC_PROG_CC, обычно используемые на начальной стадии работы скрипта configure, оптимизированы и больше не вызывают так много вторичных макросов. Изменение позволяет выявить несколько классов ошибок, как правило, вызванных использованием макроса AC_REQUIRE;
  • Макросы, принимающие списки аргументов, разделённых пробелом, теперь всегда раскрываются с каждым из перечисленных аргументов. Изменение затрагивает макросы AC_CHECK_FILES, AC_CHECK_FUNCS, AC_CHECK_FUNCS_ONCE, AC_CHECK_HEADERS, AC_CHECK_HEADERS_ONCE, AC_CONFIG_MACRO_DIRS, AC_CONFIG_SUBDIRS и AC_REPLACE_FUNCS;
  • Добавлены новые макросы AC_C__GENERIC, AC_CONFIG_MACRO_DIRS и AC_CHECK_INCLUDES_DEFAULT;
  • В макросе AC_PROG_CC при наличии теперь выбирается компилятор с поддержкой C11 (с откатом до C99 и C89, если не найден), а в AC_PROG_CXX - C++11 с откатом до C++98. Макросы AC_PROG_CC_STDC, AC_PROG_CC_C89 и AC_PROG_CC_C99 объявлены устаревшими.


  1. Главная ссылка к новости (https://lists.gnu.org/archive/...)
  2. OpenNews: Релиз GNU autoconf 2.69
  3. OpenNews: Разработчики OpenBSD подчеркнули проблемы с поддержкой не-GNU платформ в Autoconf
  4. OpenNews: Вышел GNU Autoconf 2.65, теперь под лицензией GPLv3
  5. OpenNews: Релиз генератора файлов сборки GNU Automake 1.16
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/53361-autoconf
Ключевые слова: autoconf, build, make
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (56) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, m.makhno (ok), 11:33, 15/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +13 +/
    > После восьми лет с момента публикации версии 2.69

    Firefox, Chrome и пр., смотрите - остались ещё люди в этой индустрии, которые никуда не торопятся и собирают версии по существу.

     
     
  • 2.2, Аноним (2), 11:36, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты мониторишь все статьи чтобы быть первым? А так да, всё по существу.
     
     
  • 3.3, m.makhno (ok), 11:39, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Да нет, так получается. Вообще настроена RSS лента в браузере да есть подписка на канал в Telegram.
     
  • 3.5, Аноним (-), 12:03, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    По-существу, главное чтобы быть быстрее тебя, Аноним.
     
  • 2.6, Аноним (6), 12:15, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Ты версию less или systemd видел?

    С другой стороны, а какая разница? Это всего лишь циферка. Главное, чтобы они по порядку шли.

     
  • 2.7, Аноним (7), 12:17, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > никуда не торопятся и собирают версии по существу

    Давай чисто для прикола сравним количество изменений Autoconf 2.69...2.69b и, скажем, хромиумовское 83.0.4103.116...84.0.4147.89.

     
     
  • 3.9, m.makhno (ok), 12:32, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    «по существу» подразумевает полезность изменений, а не скрытие URL в адресной строке или удаление а потом возвращение кнопки «Закрыть все вкладки справа» или вырезанный FTP
     
     
  • 4.10, Аноним (7), 12:35, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Да, корпорация гугл занимается только сокрытием урлов и возвращением свежеубранных кнопок. Посмотри сам: ВСЕ коммиты связаны только с этим - https://chromium.googlesource.com/chromium/src/+log/83.0.4103.116..84.0.4147.8 (жми Next в конце страницы пока не надоест).
     
     
  • 5.11, m.makhno (ok), 12:52, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    сама корпорация дохрена чем занимается помимо Chrome, спору нет
     
  • 2.18, Аноним (-), 17:43, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Жаба с гадюкой их все же куснули - "потенциально могут привести к нарушению совместимости с существующими скриптами Autoconf"
     

  • 1.4, Аноним (4), 11:54, 15/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    >при наличии теперь выбирается компилятор с поддержкой C11 (с откатом до C99 и C89, если не найден), а в AC_PROG_CXX - C++11 с откатом до C++98

    В 2036 поддержат C++20.

    В общем, в топкy.

     
     
  • 2.8, Повидло19 (?), 12:18, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы совершенно не понимаете автотулзы.
     
     
  • 3.12, Pistrun (?), 15:44, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А его кто-то кроме авторов понимает?
     
     
  • 4.14, Michael Shigorin (ok), 16:19, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Махоткин, говорят...

    PS: в смысле autobook дочитал.

     
     
  • 5.23, анончик (?), 20:00, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    тю, он уже лет 15 как менеджер и автотулз уже давно не его проблемы.
     
  • 5.32, Аноним (-), 09:18, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Интересеные у вас в Альте отношения: "Так а ты иди штудируй маны. Чтобы к завтрашнему дню от зубов отскакивало".
     
  • 4.16, Повидло19 (?), 16:53, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Поясняю, автотулзы прозрачны, если не мудрить, они не стоят у вас на пути. Если скрипт не распознает ваш компилятор, то можно просто указать ./configure CC=megacompiler-c-2036. И всё поедет.

     
     
  • 5.17, CAE (ok), 17:04, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    AC_PROG_CC ставит OBJEXT and EXEEXT один раз. Второй вызов надо сделать - добро пожаловать в обёрточную шелл-функцию.
     
     
  • 6.20, Повидло19 (?), 17:50, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это зависит от платформы, а не от компилятора, и строго говоря, вообще не имеет значения.
     
  • 5.22, Аноним (22), 18:53, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > автотулзы прозрачны, если не мудрить

    Не поможет. Их авторы уже тыщу раз перемудрили.

     
     
  • 6.43, anonymous yet another (?), 22:55, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Согласен. IMO, там целеполагание вышло невменяемое, а результат
    соответствует этому целеполаганию.
     

  • 1.13, mos87 (ok), 15:47, 15/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    нужно
     
  • 1.15, CAE (ok), 16:45, 15/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Пора уже продвигать mk-configure взамен.
     
     
  • 2.19, Аноним (19), 17:49, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А оно поддерживает столько же неведомой фигни? А то сабж вроде даже под досом можно изгальнуться, с DJGPP каким.
     
  • 2.24, Аноним (24), 20:25, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это которому бсдшный make нужен ? B печку его !
     
  • 2.41, Michael Shigorin (ok), 22:27, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Пора уже продвигать mk-configure взамен.

    У него, к сожалению, и другие косяки недавно всплыли.  Похоже, при дизайне Лёша такого не ожидал (он в курсе).

     
     
  • 3.54, CAE (ok), 13:25, 20/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > У него, к сожалению, и другие косяки недавно всплыли.  Похоже, при
    > дизайне Лёша такого не ожидал (он в курсе).

    Подробности секретны? Можно в почту?

     
     
  • 4.55, Michael Shigorin (ok), 15:39, 20/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> У него, к сожалению, и другие косяки недавно всплыли.
    >> Похоже, при дизайне Лёша такого не ожидал (он в курсе).
    > Подробности секретны? Можно в почту?

    Подробности публичны, просто тогда меня хватило хотя бы заикнуться, а сейчас вспомнил точнее и нашёл ссылку -- см. окрестности http://lists.altlinux.org/pipermail/devel/2020-May/210939.html

    (у меня тоже такое было "ой, об этом не подумал"; немножко утешало разве что когда-то прочитанное в архиве openwall письмо Solar Designer насчёт "ой, а про чрут в чруте не подумал")

     

  • 1.21, Аноним (22), 18:48, 15/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кто в здравом уме сейчас этим пользуется?
     
     
  • 2.25, Андрей (??), 21:15, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    КриптоПро. Мы собираем CSP под Linux, macOS, iOS, AIX, FreeBSD, Solaris, Android на intel/power/sparc/arm/mips/эльбрус. И соберём на N+1 платформе и M+1 архитектуре. Никаких аналогов нет.
     
     
  • 3.26, Аноним (26), 21:24, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Врёте, это умеет любая современная система сборки.
     
     
  • 4.28, Повидло19 (?), 01:46, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ананим не понимает, что если любая система сборки справляется, то никакая система сборки и не нужна.

    А вот взять только Линукс и Солярис - там начинаются чудеса: https://www.oracle.com/solaris/technologies/linux-app.html

    И даже cmake уже не тянет.

     
     
  • 5.33, Аноним (22), 11:48, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Брехня. У нас даже тупейший boost.build справляется со сборкой под linux, freebsd и solaris, что уж говорить про cmake. А если ты только чужой код умеешь собирать, так речь не об этом.
     
     
  • 6.38, Аноним (38), 22:14, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Угу, когда попробуешь забилдить под AIX или там аль-полено какое - тогда и расскажешь как тебе твой бустбилд.
     
     
  • 7.53, Аноним (22), 11:52, 17/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Под полено тоже собираем, не переживай. Будет надо — и под AIX соберём.
     
  • 4.30, Аноним (30), 07:57, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это ты врёшь, не любая система сборки поддерживает все эти цели.
     
     
  • 5.31, Грисс (?), 08:58, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да, но тем не менее все легко можно осилить Scons-ом
     
     
  • 6.40, Michael Shigorin (ok), 22:26, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Да, но тем не менее все легко можно осилить Scons-ом

    А этот кусок всё того же писали те, у кого даже я принципиальный баг про -Wl,--as-needed нашёл давным-давно.  Ну то есть полностью профнепригодные.

     
  • 6.44, Аноним (44), 23:02, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Из всех билд систем вы выбрали наиболее отстойную :)
     
  • 4.39, Michael Shigorin (ok), 22:25, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Врёте, это умеет любая современная система сборки.

    Врёте здесь Вы.  Автокрап оказался вменяемым на фоне того дерьмища, особенно шмяка и _особенно_ waf, которое понаклепали возомнившие себя способными сделать что-то лучше импотенты.

     
     
  • 5.46, Аноним (22), 23:58, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ещё один врун пришёл… Только про waf — правда, остальное — брехня.
     
  • 3.34, Аноним (22), 11:53, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это не аналогов нет, это у вас, похоже, специалистов нет окромя старпёров, котор... большой текст свёрнут, показать
     
     
  • 4.42, Michael Shigorin (ok), 22:31, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > $ ls /usr/share/cmake-3.13

    Какие там плюсы были этому поделию нужны для сборки?
    (это ещё не затрагивая тот гадюшник из "стандартов", который они сами себе уже устроили)

    Не видели здесь ничего лично Вы.  Ни того ксеникса, ни чего-либо отличного от x86 и, может быть, arm.  Латентный винтелоид, как и те шмякоделы.

     
     
  • 5.45, Аноним (22), 23:56, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ой, ты не осилил патчик для ель-бруса запилить? Ну извиняй, больше это никому не нужно.
    Если что, я cmake'ом благополучно собирал проекты под amd64, arm64, e2k-4c, i386 и mipsel. Проблем, связанных именно со сборочной системой, не заметил нигде. Что-то не так делаю, вероятно.
     
     
  • 6.49, Аноним (22), 00:11, 17/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > под amd64, arm64, e2k-4c, i386 и mipsel

    Ой, забыл. Ещё под все архитектуры, поддерживаемые Fedora 3-4 года назад.

     
  • 6.56, Michael Shigorin (ok), 16:06, 20/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Ой, ты не осилил патчик для ель-бруса запилить?

    Видите ли, патчик для автокрапа потребовался один, несложный и за последующие пять лет не тревожил: http://lists.gnu.org/archive/html/config-patches/2015-03/msg00000.html

    Да, порой до сих пор пригождается что-то вроде

    ---
    cp -aLt . -- /usr/share/automake/config.{guess,sub}
    --- http://altlinux.org/эльбрус/портирование

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

    Но насколько же это меньше проблем, чем "я не собираюсь cmake менее чем x.y.z", а он, соответственно, уже "переехал на новый стандарт", а новый тулчейн тащить в тяжёлых случаях бывает тоже тем ещё приключением (сейчас про e2k говорю, но на x86 тоже сплошь и рядом бывало).

    И плюс ещё приятные мелочи вроде jsoncpp/libuv, в которые Вы тоже, поди, не лезли, потому как всё уже на блюдечке, другими сделанное (но хоть rhash из "странных" зависимостей проблем не доставлял).

    Или вот такое: http://gitlab.kitware.com/cmake/cmake/issues/17126

    > Что-то не так делаю, вероятно.

    У Вас сколько этих проектов?  А у меня сейчас -- более семисот из >14000 пакетов в sisyphus_e2k.  Причём самого разного авторства и качества (в том числе благодаря и регрессиям при переходе с auto* на шмяк).

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

     
  • 4.50, anonymous yet another (?), 00:56, 17/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    "дедушка, вы тоже так говорите". Когда доходит до чего-то чуть-чуть нетривиального,
    автокрап и cmake стоят друг друга. Концептульная дрянь --- оба. Латать косяки
    автокрапа, правда, получается чуть легче (если только авторы весь дебилизм libtool'а
    не врубают --- в патологических случаях уже только ампутация).
     
     
  • 5.51, Аноним (22), 10:51, 17/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Мой опыт говорит о другом В cmake всё бывает плохо только в том случае, когда к... большой текст свёрнут, показать
     
     
  • 6.52, anonymous yet another (?), 11:16, 17/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> Когда доходит до чего-то чуть-чуть нетривиального, автокрап и cmake стоят друг друга.
    > Мой опыт говорит о другом.

    Видимо, я опытнее.

    > В cmake всё бывает плохо только в
    > том случае, когда криворукий разработчик накосячил в CMakeLists.txt.
    > Увы, за гибкость
    > инструмента приходится платить возможностью такого. А в автокрапе многое криво by
    > design. Не говоря о необходимости таскать вместе с исходниками гору нагенерированных
    > скриптов, объёмом превышающую сам код проекта, причём зачастую — во много
    > раз.

    Я не адвокат ни того ни другого. Обе "хороши". И cmake ничуть не лучше.

    >> Латать косяки автокрапа, правда, получается чуть легче (если только авторы весь дебилизм libtool'а не врубают --- в патологических случаях уже только ампутация).
    > Без libtool в сколько-нибудь сложных проектах не обойтись,

    Сильно неправда.

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

    Иногда он не сильно мешает. Иногда его можно заткнуть.
    Но встречаются и эпичные случаи.

    > В простых же
    > проектах a'la helloworld и голого make хватит.

    Для типовых случаев разница в сопровождении не велика
    и не принципиальна. Для сложных вещей --- цена сопровождения
    систем с "чистыми" make-файлами на два порядка ниже
    любой их упомянутых здесь двух.

     

  • 1.27, Аноним (27), 22:03, 15/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    m4 это жесть, bloatware как оно есть
     
     
  • 2.47, Аноним (22), 00:00, 17/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Сам по себе m4 — не такая уж плохая штука, хоть и с упоротым синтаксисом. Но то, что на нём навертели в сабже — за гранью добра и зла.
     

  • 1.29, Анонолекс (?), 06:39, 16/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Нормуль, новость, одобряю. Ордам нубов наверняка не интересно/не в курсах/не дойдёт, что autoconf умеет не только Си, с плюсами и без, но и кучу других полезных, годных языков. У меня в одном самопильном проектике он даже с bash/ash/*sh пригодился...

    А когда речь идёт о проекте, написанном на нескольких языках... Да, школота, есть и такие. Что может быть лучше? Я не ругаю другие системы сборки, Cmake мне тоже нравится. Но он пока сыроват. Имхо.

     
     
  • 2.35, анончик (?), 15:39, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > проекте, написанном на нескольких языках

    да-да, тогда обязательно нужен autotools, чтобы запустить gradle, yarn и go build.

     
     
  • 3.36, microsoft (?), 18:01, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ага тото в каждом проекте сотни сотни миллионы скриптом оберток над ними. Проще некуда ага...
     
     
  • 4.37, анончик (?), 19:56, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    я скажу так: чтобы написать makefile, вызывающий go build, автотуулз явно не нужен и даже мешает.
    автотуулз -- это именно генератор makefile, на минуточку.
     
     
  • 5.48, Аноним (22), 00:02, 17/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Чтобы запустить go build, и makefile писать не надо.
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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