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

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

У нас есть 14 конкурирующих стандартов, это никуда не годится. Нужно сделать новый стандарт, который устаивает всех.

В apt дистрах можно из сорцов собрать, это несложно. А почему не любят GNU Autotools – так это вкусовщина.

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

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

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

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

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

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

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

Это ж главный хайкеист всея Лора, знать уже надо.

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

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

Я знаю, но я хочу попробовать «посмотреть на обсуждаемый предмет с его стороны». Ща посмотрим, что он ответит( если ответит вообще).

бох дал вам meson

А, ну тогда это многое объясняет. По крайней мере, теперь у меня есть понимание вашей ненависти.

Кстати, а гнутым пробовали писать на тему поддержки и помощи с портированием?

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

Начать с make, добавить

нет пути

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

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

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

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

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

Craptools

К логопеду!

все

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

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

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

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

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

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

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

Craptools

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

<stdbool> это из C99? В cmake можно прописать c_std_99 в target_compile_features.

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

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

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

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

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

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

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

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

Вот, например, в configure от mc

Почти мегабайтный, это же ужас!

Все можно протестировать, если надо.

Мне казалось они у всех не совсем мелких проектов такие. У пхп например 2-3 мегабайта.

Чтобы они там заработали, туда надо таскать пол-юникса

Для справки. Установщики занимают:

• 84 MB - msys2 (надо ещё бы добавить зависимости autoconf)
• 38 MB = 13 MB - meson + 25 MB - python
• 32 MB - cmake

Но править надо всего лишь 21 KB configure.ac.

Не суть. Меня пугают уже первые 30 строк. :)

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

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

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

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

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

ППКС

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

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

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

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

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

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

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

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

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

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

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

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

На винде и маке этот автотулз работает?

Потому, что они кривое говнище: https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213

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

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

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

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

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

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

На винде и маке этот автотулз работает?

Разумеется. На винде даже с msvc можно использовать.

На маке – да, под виндой – нет.

Да? Я почему-то всегда думал что нельзя. Покажете как?

Наследие культуры разработки ПО в Unix, не особо хорошо воспринамается в «GNU».

Покажете как?

Например, с помощью https://github.com/swig/cccl

под виндой – нет

С mingw вообще из коробки работает

А как configure запустить? Там же шэл-скрипт.

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

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

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

Да нет, кривой тут кто-то другой, чей домен в твоём урле указан.

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

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

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

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

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

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

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