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

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

Не подскажете как мне сам «configure» сгенерировать в каталоге сборки и не замусоривать исходники?

Не у кого-то другого происходит silent misconfigure вместо выдачи ошибки. Но я конечно понимаю, что лоровский путь это попытаться вбросить не разбираясь в вопросе.

Конечно, работает. Чего же ему не работать? Но что в нём там такого особенного? Простая, базовая штука. Всё это работает на разных платформах, и проект собирается довольно тривиально. Против Meson тоже ничего не имею.

configure функционирует как часть исходников, поэтому всегда должен находиться в корне. Чтобы его не коммитить в git, достаточно настроить .gitignore.

Это правда.

misconfigure происходит из-за дефективного системного компилятора. С дефективным компилятором и не такое может произоёти, винить в этом его пользователей не следует.

Если что, автотулзы я тоже не люблю, но по ссылке определённо не их вина.

Это происходит из-за дефективных тестов автотулзов. Компилятор рабочий, соблюдает стандарт в этом случае. С автотулзами неизвестно, на каком пустом месте они споткнутся в следующий раз.

Компилятор дефективный, падает на компиляции тривиального кода. Общепризнанно дефолтное поведение Си-компиляторов - это без -Werror в любом его виде. Так было всегда, и на это много кто рассчитывал, но шланг-умники уже не первый раз решили повоспитывать своих пользователей, за что и поплатились этим позором. Хорошо бы ещё пакостную неотключаемую ошибку на нестандартный прототип main() - она даже не Werror а захардкоженная именно ошибка - так же убрали. Компилятор НЕ должен мешать программисту писать любой код. Безальтернативное падение допустимо только если код вообще непонятно как компилировать, всё остальное это варнинги - программиста предупредил, ок, но работай дальше.

Если что, весь свой код я компилирую с -Werror -Wimplicit (и шлангом не пользуюсь), но эти флаги я добровольно вписал а не по воспитанию от каких-то умников.

Тесты автотулзов хрупкие, потому что не могут отличить ошибку в тесте от отсутствие тестируемой фичи. Надеяться на негарантированное поведение компилятора это плохой дизайн.

configure – это никакие не исходники, а результат генерации, тоже что и генерируемые makefile.

достаточно настроить .gitignore

Как мне это поможет если исходники лежат в squashfs или NFS с доступом только на чтение?

Потому что все привыкли собирать под свою или ещё какую целевую тачку и всё, есть ли нужные функции, макросы, флаги и опции компилятора. Ну, как бог пошлёт. А GNU Autotools это система созданная для того чтобы собрать что угодно, на чём угодно, даже на том чего не существует или экзотика лютая. Не любят потому что он много генерирует. Много чего делает непонятного, кучи правил и всего такого. Там надо разбираться. И понимать как работает софт. Наверное если брать к примеру не знаю, сделать сборку софта под PlayStation или под новый проц вчера придуманной архитектуры с заголовками со стороны, зависимостями и библиотеками да ещё с левым компилятром, то GNU Autotools нет равных. Он пережуёт все опции, выявит тех что нет, выяснит делают ли они то что нужно, проверить функции и прочее прочее. Он в процессе работы своей проверяет систему не читая там конфиги описывающие что-то, а никому не верит, если нужно проверить наличие функции он её прям в процессе скомпилирует. И кучи ещё других дел. Это всё очень надёжно, мощно и круто. Но не быстро.

GNU Autotools это по сути такая коллекция набитых шишек, от переноса ПО на множество различных архитектур или программных окружений. Но, сложна :(

GNU Autotools это по сути такая коллекция набитых шишек, от переноса ПО на множество различных архитектур или программных окружений.

не очень переносимая. Требует bash и прочей gnu фигни.

Из powershell не работает. А cmake/meson работают.

не могут отличить ошибку в тесте от отсутствие тестируемой фичи

негарантированное поведение компилятора

Это гарантированное поведение любого нормального компилятора с начала времён и по настоящее время. Дефективный же компилятор, коим является шланг, может не гарантировать вообще ничего. Впрочем, проблема в тестах таки есть, но в другом месте, см. ниже.

Код типа «main() { somefunc(); }» гарантированно компилируется любым нормальным компилятором начиная с 70-х годов (или когда там Си появился) и по настоящее время, вне зависимости от реального существования этой функции. А вот линкуется негарантрированно, во-первых функции и правда может не быть в libc (это как раз то что мы пытаемся выяснить), а во вторых она может быть макросом - и тут у автотулзовых тестов и правда проблема, без соответствующего хедера макрос будет не виден и тест ложно-провалится.

Требует bash и прочей gnu фигни.

Враньё. Баш там точно не нужен, даже для той их части что генерирует configure. Нужен дурацкий m4. А для уже сделанного configure вообще ничего кроме posix шелла не нужно. А, ну ещё gnu make наверно нужен.

А cmake/meson

Будто не требуют :D

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

В gcc тоже нужно в определённых случаях указывать -fpermissive, выходит оба основных компилятора дефективные. Сборка софта на этом отваливалась.

собирай мавеном >_>

CMake нормально работает в паре с Ниндзей под Шишдовсом. А вот Маязон я ещё не пробовал там запускать.

Я пробовал, работает (в git bash).

Компилятор НЕ должен мешать программисту писать любой код.

Потом удивляемся горам CVE в сишных программах.

Ставишь asdf-vm, затем плагин:

https://github.com/asdf-community/asdf-cmake

ПользователИ некродистров как правило страдают аутизмои, а поэтому не в состоянии даже несурьезные проблемы победить, тогда как арчебоги и гентуфилы постоянно сталкиваются с ломающими обновлениями и задрочились на их решении

Так. А как конпелятор твои ошибки логики проверит? Вот сурьезная ошибка в браузерах, когда зам счет специального заголовка можно было выполнить любую команду на твоей машине… Вот примеры сурьезных CVE. Конпелятор только твою дрисню переводит в машинные коды, и ОН БОЛЬШЕ НИЧЕГО НЕ ДОЛЖЕН ДЕЛАТЬ

Static Analyzer

Он тебя не спасет. Нужно тесты писать

А GNU Autotools это система созданная для того чтобы собрать что угодно, на чём угодно, даже на том чего не существует или экзотика лютая.

Лютое 4.2. Вы хоть сами пробовали собирать проекты на Craptools в экзотических ОС и железе? Или просто мифов начитались и свято им верите? Один из частых аттракционов это например выпиливание захардкоженной зависимости -ldl когда в целевой ОС эта библиотека называется иначе, либо является частью libc. И замучаешься искать где оно конкретно захардкожено и что править, у поиска по двум буквам слишком много ложнополржительных срабатываний. И это только малая часть сборки под не попсовые платформы.

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

implicit функции - это не ошибка, сколько тебе повторять? Ошибкой они стали только в фантазиях шлангописателей.

Нечего слабоумных до программирования допускать и не будет гор CVE. Компилятор тут не виноват.

Если тест будет прибит OOM-киллером, например, оно точно так же мисконфигурирует. Компилятор тут вообще нипричём. И с gcc аналогичный затык возможен.

Да, а ещё я уже упомянул про проблемы когда функция окажется макросом. Но по конкретно той ссылке - виноват шланг.

Дооо. Это были неправильные сишники. Знакомая песня. Только вот где эти правильные сишники и почему они не разрабатывают софт не понятно.

Make кардинально не менялся с, вроде, 90-х. Почему на него не переехать?

Такие тесты могут быть нужны в другом случае: когда например нужно time(), но оно то ли в time.h то ли в sys/time.h

Да, твой пример удачнее моего.

Видимо, они разрабатывают. Но не для всех. :)

Код типа «main() { somefunc(); }» гарантированно компилируется любым нормальным компилятором начиная с 70-х годов (или когда там Си появился)

Не указывать возвращаемый тип – это ошибка начиная с C99, так что Clang тут прав. Хотите чтобы оно компилировалось, добавляйте флаг --std c89.

А может это надо -std=c99 добавлять если хочешь чтоб компилятор форсировал какие-то необщепринятые ограничения? gcc кстати ни в каком из режимов это не запрещает, но -std=c99 у него никогда не был дефолтом. Дефолтом было -std=gnu99 когда-то, а теперь наверно gnu17. Есть ли в стандарте «GNU C17» запрет на это - вопрос не очевидный, думаю надо ориентироваться на gcc который не запрещает.

Суть в том что не надо ломать обратную совместимость.

Суть в том что не надо ломать обратную совместимость.

Совместимость сломали в стандарте Си, так что обращайтесь в комитет по стандартизации, а не Clang. Использовать версию языка 30+ летней давности по умолчанию – абсурдная идея.

Что ты прицепился к этому стандарту? Есть системная команда cc, она должна уметь компилировать main() { qwe(); } в объектный файл. Совершенно плевать, чем она при этом будет руководствоваться. Отвечают за это авторы команды, а не какие-то графоманы-стандартописатели.

Более того, по-моему не все компиляторы вообще поддерживают -std= и точно не все компиляторы совместимы с gcc по синтаксису настроечных аргументов. Но синтаксис «cc -o obj.o src.c» поддерживают все и он должен быть обратно совместим с первыми юниксами.

Есть системная команда cc, она должна уметь компилировать main() { qwe(); } в объектный файл.

В каком стандарте написано что должна уметь?

и он должен быть обратно совместим с первыми юниксами.

Кому нужны первые Юниксы? Они давно уже EoL.

В каком стандарте написано что должна уметь?

В стандарте «обратная совместимость хороших операционных систем». Графоманы его наверно ещё нигде не записали, но это не отменяет его важности. А вот того, что команда «cc» должна компилировать в соответствии с ISO C99 - и правда нигде не написано. Для этого есть (сюрприз?) команда c99 (POSIX).

Кому нужны первые Юниксы? Они давно уже EoL.

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

обратная совместимость хороших операционных систем

Как связаны операционная система и компилятор?

А вот того, что команда «cc» должна компилировать в соответствии с ISO C99 - и правда нигде не написано. Для этого есть (сюрприз?) команда c99 (POSIX).

Как наличие команды c99 запрещает команде cc компилировать в C99 по умолчанию?

Преемственность не должна нарушаться.

Все должны грызть кактус убогих систем из 80-х чтобы что?

И косяк в данном случае однозначно на стороне убогих autotools, в которые не осилили прикрутить чек на предмет используемого по умолчанию компилятором стандарта и передавать соответствующие флаги в своих проверках в зависимости от этого.

Как связаны операционная система и компилятор?

Так что cc это такая же базовая команда операционной системы как cp или echo. Так что если компилятор претендует быть дефолтным юникс-компилятором (тем что по команде cc) то он должен соответствовать ожиданиям от дефолтного юникс-компилятора. Впрочем да, тут не только шланг виноват, а и те, кто додумались его в cc поставить.

Как наличие команды c99 запрещает команде cc компилировать в C99 по умолчанию?

Никак, дело не в ней, а в нарушенной совместимости.

Все должны грызть кактус убогих систем из 80-х чтобы что?

Ты о чём? С каких пор поддержка обратной совместимости стала кактусом? И заметь - у тебя никто не отнимает возможности компилировать в C99 - просто укажи -std=c99. Или вон даже короткую команду сделали без флагов про которую я выше написал. Но не надо ломать обратную совместимость команды cc.

И косяк в данном случае однозначно на стороне убогих autotools, в которые не осилили прикрутить чек на предмет используемого по умолчанию компилятором стандарта и передавать соответствующие флаги в своих проверках в зависимости от этого

Повторю ещё раз: проблемы начались с 15-го шланга. Никто раньше до такой дури не додумывался и соответственно проверять было нечего. Теперь наверно что-нить прикрутят (с пометкой «поддержка забагованного компилятора»). Но надо учитывать, что есть другие компиляторы, которые упадут от флага -std который они не поддерживают, так что прикручивать не так просто и логика станет ещё запутаннее, спасибо шлангу за это - на ровном месте создали проблему.

Так что если компилятор претендует быть дефолтным юникс-компилятором

Каким образом это накладывает ограничения на используемый по умолчанию стандарт?

Ты о чём? С каких пор поддержка обратной совместимости стала кактусом?

С момента накладывания ограничений типа «не выставляйте современный стандарт по умолчанию», «shell должен быть POSIX-совместимым», «grep должен быть без -E по умолчанию» и так далее, которые усложняют жизнь всем, кроме 1.5 пользователей сдохших юниксов.

Повторю ещё раз: проблемы начались с 15-го шланга.

Проблемы начались с создания autotools в виде кривого генератора портянок из портянок.

Но надо учитывать, что есть другие компиляторы, которые упадут от флага -std который они не поддерживают

Да, упадут. Autotools, правда, и так эти проверки будет обязан выполнять, так как у таких компиляторов и другие флаги не будут работать должным образом, так что никакого реального влияния ни на что это не окажет.

Причем обрати внимание: все нормальные системы сборки используемый стандарт в команду компиляции передают, потому что никто не хочет завязываться на дефолты, которые сегодня одни, а завтра другие. И никаких проблем с этим у них нет.

А у портянок из 80-х на кривой макросне, которые писались для поддержки зоопарка деревянных (и уже сгнивших) недосистем – есть.

Я точно не знаю про этот проект, но проекты GNU часто не соблюдают стандарт. В GNU Coding Standards прямо так и написано, что программисту не следует ограничивать себя в расширениях стандарта в том случае, если он точно знает, что на всех платформах работает GCC.

For instance, Standard C says that nearly all extensions to C are prohibited. How silly! GCC implements many extensions, some of which were later adopted as part of the standard. If you want these constructs to give an error message as “required” by the standard, you must specify ‘--pedantic’, which was implemented only so that we can say “GCC is a 100% implementation of the standard”, not because there is any reason to actually use it. 

Some programmers like to use the GCC ‘-Wall’ option, and change the code whenever it issues a warning. If you want to do this, then do. Other programmers prefer not to use ‘-Wall’, because it gives warnings for valid and legitimate code which they do not want to change. If you want to do this, then do. The compiler should be your servant, not your master. 

(C) GNU Coding Standards

Проекты GNU соблюдают стандарт GNU. А что там всякие ISO-комитеты награфоманили - дело десятое. У ISO-комитета даже своего компилятора нет, так что он не авторитетен. Но чтоб авторов gcc не обвиняли в якобы неспособности реализовать ISO-стандарт - сделали этот бесполезный ключ -pedantic и предостерегли всех от его использования.

Только вот стандарта «GNU C» нету.

На фряхе вроде BSD make, а не gmake используются.

Чеки для проверки компилятора есть, но их не использовали. Действительно, cc должен жевать ANSI C. Так было всегда во всех системах.

Да здрасьте. А -std=gnu89, -std=gnu99, -std=gnu11, -std=gnu17 это что?

На фряхе есть системный make и можно установить порт gmake. В базовой системе (где нет gmake) автотулзов тоже нет. А вот есть ли порты, которые используют автотулзы, но при этом не требуют gmake - не знаю.