LINUX.ORG.RU

Почему все так не любят GNU Autotools?

 , , ,


0

1

Недавняя новость удивляет: CMake 3.28

В комментариях многие желают GNU Autotools смерти, но почему? Я свои проекты сопровождаю с ним и почему-то никаких проблем не возникает.

Последняя версия Automake обновлена: 2018-02-25
Последняя версия Autoconf обновлена: 2021-01-28

Разве это не круто? С Cmake часто возникает ситуация, когда у вас CMake версии (условно) 3.0.0.1, а проект хочет CMake 3.0.0.3 и требует его обновить. Ладно в Gentoo можно новую версию собрать, а что делать с APT дистрами? Удалять, собирать руками новую версию? А ему либы нужны тех версий, которых нет в репозиториях. Дальше что? Их тоже руками собрать?

Autotools во-первых обновляется нечасто (фактически, только bugfixы), во-вторых может переживать дремучее легаси (да, с варнингами, но пережует), а не поступит как CMake:

удалена команда exec_program(), признанная устаревшей в CMake 3.0. Вместо неё следует использовать execute_process();

Так объясните мне теперь, за что вы так Autotools не любите? Он же замечательно работает.

Перемещено hobbit из general

★★★

Слишком много слоёв абстрации. cmake я тоже не люблю. Нужно сделать новый инструмент. Начать с make, добавить ему современный синтаксис, а также добавить расширяемость (функции, библиотеки и тд). А не так, что одно генерирует другое, оно третье, оно вызывает четвёртый инструмент. Не разберёшься кто кого вызывает.

vbr ★★★★
()

Ненавижу Craptools ЛЮТОЙ НЕНАВИСТЬЮ и желаю его скорейшее уничтожение и забвение.

Работать с ним – лютый кошмар. Если пытаешься собрать под платформу, вторая не была предусмотрена автором программы, то готовься к лютой боли и страданиям: неведомым ошибкам M4, autodetect failed и прочим. Как туда что-то добавить я понятия не имею, пробовал добавить новый *.c файл и оно всё посыпалось.

Эта криворукая поделка не умеет не засирать исходники своими продуктами жизнедеятельности вроде «configure». Подавляющее большинство других систем сборки умеют хранить все гененируемые временные файлы сборки в указанной директории, а не вместе с исходниками. Это бывает важно например когда исподники в ФС только для чтения. И даже не говорите что поставлять исходники с «configure» – нормальная практика, потому что его всё равно придётся регенерировать для нетипичной платформы. Кстати сам процесс регенерации не стандартизирован и надо разбираться как это делать с каждым проектом индивидуально: у кого-то есть autogen.sh у кого-то команды написаны в инструкции по сборке, иногда ничего не остаётся кроме как действовать методом тыка.

Этот «configure» люто тормозной и зачастую собственно процесс сборки занимает меньше времени, чем конфигурирования. Оно проверяет кучу бесполезных вещей вроде особенностей старых UNIX’ов у которых давно истекла поддержка, но при этом не проверяют некоторые актуальные системы, в результате чего эту жуть приходится патчить.

Любить этот Craptools могут либо свидетели первых UNIX которые сейчас уже на пенсии, либо кто ничего кроме сборки исходников под популярные платформы не делает, исходники ни в коем случае не редактирует.

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от X512

Можно уточнить, кто вы такой в контексте автотулс?
Пользователь, который скачивает сорцы на свой компьютер и собирает программу для себя?
Мейнтейнер, который соирает пакеты для дистрибутива?
Или вы портируете программы на не типовые архитектуры и/или операционные системы?

u5er
()
Ответ на: комментарий от u5er

Или вы портируете программы на не типовые архитектуры и/или операционные системы?

This. Haiku или Линукс с riscv64. Также иногда правлю исходники под свои нужды или использую в своих проектах.

X512 ★★★★★
()
Ответ на: комментарий от u5er

Наибольшая причина ненависти в том что для меня Craptools – это чёрный ящик и я вообще не понимаю как оно работает. Оно использует технологии из прошлого столетия вроде M4 и Perl про которые уже все забыли. Оно ещё до моего рождения появилось. Я представляю как работает например Meson, сам правил его исходники на Python, но Craptools – это как открывать тайну фараонов и египетской письменности, которой уже никто не пользуется.

X512 ★★★★★
()
Ответ на: комментарий от X512

Нисколько не защищая autotools, разбирая только ваши аргументы:

вообще не понимаю как оно работает

Оно использует технологии из прошлого столетия

Оно ещё до моего рождения появилось.

Одни оценочные суждения. А мы точно не винды обсуждаем?)))

einhander ★★★★★
()

все

Ну не то, чтобы «все не любят», тут есть и поклонники. Но к автотулзам реально есть претензии.

  1. Сложно разобраться в конфигах, сложно адаптировать какой-нибудь полузаброшенный проект к современным или наоборот, специфичным системам. Даже упоротый в синьку cmake в этом плане проще.

  2. Недостаточно стандартная процедура сборки, варьирующаяся от проекта к проекту. Где-то достаточно запустить ./configure, где-то надо ещё с бубном побегать.

  3. Автотулзы под б-гомерзким офтопиком это боль. Чтобы они там заработали, туда надо таскать пол-юникса. Да, это не для всех критично. Но если я пишу не линукс-эксклюзив, а по-настоящему кроссплатформенный проект — по-настоящему переносимая сборочная система выглядит привлекательнее.

hobbit ★★★★★
()
Ответ на: комментарий от X512

А вот тут я быстренько, пока никто не заметил, перебегаю на другую сторону.

Что мне действительно понравилось в автотулзах – это возможность устоявшимися средствами насандалить в configure множество разнообразных проверок. Например, позволяет ли используемый компилятор Си использовать <stdbool>. И собирать, отталкиваясь от этого.

Современные системы сборки такое умеют? Я не утверждаю, что не умеют, я просто не в курсе.

Craptools

Ну и коверкать название нелюбимого тобой продукта — так себе идея. Сразу возникает подозрение, что по делу сказать нечего. Я понимаю, что в твоём случае это не так, но это бросается в глаза в первую очередь.

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от NickNotNick

Это же только пример был. Автотулзы позволяют запустить тесты самых разных возможностей.

Вот, например, в configure от mc я вижу тест, проверяющий наличие в системе тех или иных заголовочных файлов.

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от hobbit

Например, позволяет ли используемый компилятор Си использовать . И собирать, отталкиваясь от этого.

Современные системы сборки такое умеют?

Разумеется умеют. Есть также стандартные механизмы проверки на компилируемость и наличие символов.

X512 ★★★★★
()
Ответ на: комментарий от hobbit

Например, позволяет ли используемый компилятор Си использовать <stdbool>. И собирать, отталкиваясь от этого.

Интересно, а что ты в зависимости от наличия stdbool собрался менять в процессе компиляции? Дело в том, что код «с stdbool» будет работать только если он есть, а вот код «без stdbool» будет работать и если его нет, и если он есть. Так что если ты собрался поддерживать в своей проге второй вариант (без stdbool), то смысла писать отдельную ветку кода, единственной фичей которой будет ломаться в отсутствие stdbool, нет.

Такие тесты могут быть нужны в другом случае: когда например нужно time(), но оно то ли в time.h то ли в sys/time.h то ли ещё где-то - и тебе надо выяснить, что же именно надо заинклюдить чтоб получить этот прототип. Впрочем, мне кажется это уже 20 лет как неактуально и теперь он у всех в time.h

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)

Работает не пойми как с этими configure, шевелится словно дохлая черепаха, нет нормальной кроссплатформы, в целом выглядит как лютый костыль к make для его автоматизации, но что мешало нормально допилить сам make или сделать некий make2/make++ вопрос конечно большой.

Dr64h ★★
()

С Cmake часто возникает ситуация, когда у вас CMake версии (условно) 3.0.0.1, а проект хочет CMake 3.0.0.3 и требует его обновить

Какой кошмар!

за что вы так Autotools не любите? Он же замечательно работает

За то, что кусок write-only говна.

intelfx ★★★★★
()

Потому что Autotools такое же говно мамонта невменяемое как и Cmake. Да и все остальные системы сборки тоже. Ущербность в них заложена изначально.

thegoldone
()
Ответ на: комментарий от hobbit

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

Ну это везде так. Попробуй заставить CMake нормально работать со скриптами на каком-нибудь Tcl нормально.

Недостаточно стандартная процедура сборки, варьирующаяся от проекта к проекту. Где-то достаточно запустить ./configure, где-то надо ещё с бубном побегать.

Факт. Но почти всегда это либо просто запустить ./configure, make, либо какой-нибудь ./autogen.sh, ./configure, make

Автотулзы под б-гомерзким офтопиком это боль. Чтобы они там заработали, туда надо таскать пол-юникса. Да, это не для всех критично. Но если я пишу не линукс-эксклюзив, а по-настоящему кроссплатформенный проект — по-настоящему переносимая сборочная система выглядит привлекательнее.

Опять-таки факт, но он вполне честно заявляет, что он для *NIX и нигде больше работать не обязан. Но это не так и важно. Какой-нибудь jenkins под *NIX собирает бинарник для форточек в MinGW автоматом для каждого коммита в системе контроля версий.

Если я правильно помню, libpng под виндой нормально не собрать. И это мало кого парит. Берем хедеры, берем libpng.dll и радуемся.

Кстати для любителей meson напомню, что сам питон собирается Autotools :) И вряд ли его можно под виндой собрать из исходников.

zx_gamer ★★★
() автор топика
Ответ на: комментарий от dataman

У CMake думаю будет больше. Он генерирует мэйкфайлы без псевдоцелей. Он буквально копипастит одно и тоже столько раз, сколько файлов в проекте.

zx_gamer ★★★
() автор топика
Ответ на: комментарий от zx_gamer

Но это не так и важно. Какой-нибудь jenkins под *NIX собирает бинарник для форточек в MinGW автоматом для каждого коммита в системе контроля версий.

Ну это аргумент, да. Если речь идёт про какой-то сложный коммерческий проект, где одноразовые усилия по настройке среды сборки незначительны на общем фоне затрат на разработку — так оно и есть. А вот для небольшого инди-разработчика задача может оказаться не то, чтобы непосильной, но весьма трудоёмкой.

hobbit ★★★★★
()
Ответ на: комментарий от X512

Если пытаешься собрать под платформу, вторая не была предусмотрена автором программы, то готовься к лютой боли и страданиям: неведомым ошибкам M4, autodetect failed и прочим

Собирал кучу всего под mips и sh4, собиралось без проблем, главное ключик для архитектуры правильный поставить.

Эта криворукая поделка не умеет не засирать исходники своими продуктами жизнедеятельности вроде «configure».

Умеет. Достаточно вызвать configure из каталога сборки, а не из корня.

Как туда что-то добавить я понятия не имею, пробовал добавить новый *.c файл и оно всё посыпалось.

Тут похоже кто-то другой криворукий.

annulen ★★★★★
()

Autotools во-первых обновляется нечасто (фактически, только bugfixы), во-вторых может переживать дремучее легаси (да, с варнингами, но пережует), а не поступит как CMake

Для сборки из тарболла иметь установленные компоненты autotools вообще не нужно — сгенерированный configure самодостаточен. А вот если нужно сгенерировать его заново, собирать софт из VCS, или автор не добавил сгенерированные файлы в тарболл (такое тоже бывает), то тут всё не настолько хорошо — в дистрибутивах не просто так пакуют по несколько версий autoconf.

annulen ★★★★★
()
Ответ на: комментарий от zx_gamer

Разумеется, нужна хотя бы минимальная юникс-совместимая среда вроде msys2. Но без неё вообще оффтопиком сложно пользоваться, в нём даже нет адекватного шелла)

annulen ★★★★★
()
Ответ на: комментарий от zx_gamer

libpng под виндой нормально не собрать. И это мало кого парит. Берем хедеры, берем libpng.dll и радуемся.

сам питон собирается Autotools :) И вряд ли его можно под виндой собрать из исходников.

Да, собрать невозможно, но бинарники откуда-то появились. Магия, не иначе.

firkax ★★★★★
()
Ответ на: комментарий от vbr

В жаваскрипте же работает, там каждый день новые тулзы для сборки

В жаваскрипте большого зоопарка сборочных тулз нет. Основные: webpack и rollup. Фактически, они управляют процессом компиляции и линковки.

Надо в С так же делать

А в сишечке нет модулей, поэтому так нельзя.

static_lab ★★★★★
()