Опубликован выпуск пакета GNU Autoconf 2.71, в котором поставляется набор M4-макросов для создания скриптов автоконфигурации для сборки приложений в различных Unix-подобных системах (на основе подготовленного шаблона выполняется генерация скрипта "configure")...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54484
в make сила, брат
Неправда! Сила - она в ньютонах!
сила - в динах!
СИ - Система Интернациональная (международная). В ней сила, как раз таки, в Ньютонах.
СИ - Сила
Си - сила!
ЛЫ - логика (ц)
Аминь, брат. СИ - ието извращенцы.ЗЫ: Хотя планковская сила рулит.
Большой фанат фунтов и инчей? :)
Use СГС, Luke.
> Use СГС, Luke.СИ в инженерии удобнее.
Конечно, инженерам же его вдалбливают как не в себя. Лучше б физику вместо выучили.
эх, чувак, была уже такая ответочка давеча -- придумай пооригинальней что-нибудь
В лошадиных силах же, а ньютоны - это для отступников, пусть сгниют их тела заживо!
В лошадиных силах мощность, а не сила.
У вас в слове "CMake" ошибка.
CMake лишь надстройка над make. Он только генерит Makefile.
>над ninja.поправил.
Цмейк дрянь мерзопакостная. Месон получше, но тоже гадость. Когда уже придумают нормальную альтернативу автотулсам.
а нафига? с ними вообще классно
premake5, GENie, wake, gn, tup, tundra, ... Добавить по вкусу.
fastbuild забыл
Это уже вообще треш, особенно наверно premake. Поэтому я и говорю, что meson довольно неплох ещё, в сравнении с тем, что существует помимо него.
треш - это всё, что написано не на C/C++
Зачем генератору мейкфайлов си? Из того что я видео, самые трешовые ограниченные и забагованные поделки были на bison (т.е. вполне себе си), а проблемы не исправлялись десятилетиями. Чем меньше си в этом вопросе, тем лучше, тут всего-то нужно собрать файл под определённые конфигурацию и платформу, что может быть проще.
meson без Питона, написанном на C, не взлетит и не поползёт.
Может, когда-нибудь на pypy запустят. Я, правда, не знаю, зачем.
> Может, когда-нибудь на pypy запустят. Я, правда, не знаю, зачем.Для меня того что он на питоне достаточно чтобы им не пользоваться. Я что, спецом для этой гадости питон ставить должен? При том что мой проект на си? Да и по сравнению с автотулсами, которые что-то выжимают из себя на любой системе где что-то отдаленно напоминающее шелл вообще есть...
llvm-project потихоньку переходит на gn+ninja
Сов падение? Или филинов?
Не думаю.
>The minimal build configuration is relatively heavyweight. There are several files required and the exact way all compilers are linkers are run must be specified in the configuration (see “Examples” below). There is no default compiler configuration.Очень прискорбно, что они вынуждены перейти на это gnо. Но как бэкенд к CMake может сойти. Но зачем, если CMake сама генерирует ninja.build?
Проектировщики gn совершили ошибку проектирования - они смешали высокьуровневое описание (списки файлов для сборки) с низкоуровневым (флаги компилятора), в результате получилось ни рыба, ни мясо. Высокоуровневая система всё равно нужна. А низкоуровневая уже есть, это ninja.
> Но зачем, если CMake сама генерирует ninja.build?Потому что gn генерирует намного быстрее CMake.
Иногда собираю всё из LLVM, поэтому заметил.
> llvm-project потихоньку переходит на gn+ninjaНу кто бы сомневался.
> Не думаю.
Просто эту пакость гугол малость сожрал. Ну вот и переваривать начал понемногу. Теперь будет чудная либа для обслуг нужд гугли. А, еще слегка эппла, они вроде слегка примазались.
Дрянью является тот кто считает другое дрянью.
> Дрянью является тот кто считает другое дрянью.Мразью является тот, кто анонимно оскорбляет незнакомых людей в интернете. Парируйте.
Qbs
С чего они вдруг решили воскреснуть?
Они и не умирали.
И если я завтра воскресну пускай я сегодня умру
(с) ва-банк
почитайте доки к аутоконф. Веселое чтиво, рекомендую.> A physicist, an engineer, and a computer scientist were discussing the nature of God. “Surely a Physicist,” said the physicist, “because early in the Creation, God made Light; and you know, Maxwell’s equations, the dual nature of electromagnetic waves, the relativistic consequences...” “An Engineer!,” said the engineer, “because before making Light, God split the Chaos into Land and Water; it takes a hell of an engineer to handle that big amount of mud, and orderly separation of solids from liquids...” The computer scientist shouted: “And the Chaos, where do you think it was coming from, hmm?”
—Anonymous
...
> Instead, they individually test for the presence of each feature that the software package they are for might need. (Before each check, they print a one-line message stating what they are checking for, so the user doesn’t get too bored while waiting for the script to finish.)...
> Those who do not understand Autoconf are condemned to reinvent it, poorly. The primary goal of Autoconf is making the user’s life easier; making the maintainer’s life easier is only a secondary goal.https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/a...
> The primary goal of Autoconf is making the user’s life easier; making the maintainer’s life easier is only a secondary goal.Хыхы, да. Верно подмечено. Именно поэтому разработчики и заменяют autoconf на альтернативы.
... учитывая, что пользователи вообще не контактируют с autotools ...
Определение пользователя в студию!
Те, кто запускает автотулс, являются пользователями [автотулса]
Это же справедливо и для SQL -- все, кто составляют SQL-выражения, являются пользователями [базы данных] -- SQL сделан для пользователей, а ISAM -- для программистов SQL.
Каждую новость про autoconf я жду как праздник
Я жду как праздник новости о том, что дистры сговорились и выпилили весь софт, использующий autotools, из репозиториев.
> Я жду как праздник новости о том, что дистры сговорились и выпилили
> весь софт, использующий autotools, из репозиториев.Я бы станцевал на твоей могилке. Это был бы праздник.
И будете руками makefile'ы колхозить.
эх а раньше писали в текстовиках и компилили gcc. прогресс на всю голову. я понимаю попытка ускорить, но походу только усложняют и запутывают. причем себя в том числе. потом ловят вечные cve или баги несовместимости то с одним , то с другим.
Ага, все писали и понаписали такого, что без автотулз не разрулить.
> Ага, все писали и понаписали такого, что без автотулз не разрулить.и не говори пишут что попало))))
Мне лично нравится и autoconf и make. В них столько мудрости накопленно, что меня удивляет и даже немного раздражает, что всё новые билд-системы вместо того, чтобы изучить и перенять всё лучшее из autoconf и make, изобретают свои никчёмный велосипеды.Autoconf ценен за накопленный опыт сборки на огромном количестве unix-систем. Его нужно использовать, а не выкидывать!
Make многие любят за мощный декларативный синтаксис. Не json и xml!
Если взять всё лучшее из этого всего, и заменить некроссплатформенное (читай, неработающее в Виндоус), то получаем параметры:
- декларативный синтаксис. Не json, и xml, а очень мощный prolog-like синтаксис как у make
- кроссплатформенность(своя реализация posix туулз на всех системах, например на C. Не должно быть сложно. Буквально каждый game-engine это делает сейчас)
- онлайн база знаний о системах, как autoconf-archive, или cmake'овские FindXXX(очень натянуто), только прямо чтобы онлайн, и всегда доступная без движений программистов. Прямо "коллективнаях база знаний" обновляемая и получаемая автоматически.
То есть, в моем понимании, это должна быть система, наверное, на swi-prolog или mercury, где есть центральная база знаний о всех используемых системах, которая подтягивается онлайн, во время сборки или по запросу(если нет интернета, например, на CI).В которой можно было бы писать высокоуровневые предикаты, как, например, какой файл использовать в сборке. А низкоуровневые бы писались разработчиками ос и дистрибутивов.
До сих пор, autoconf и и make этому соответствуют. До сих пор.
Не считая, что под Винду работает с трудностями. Но это из-за unix-toolsПосему вопрос. Почему до-сих пор, никто не попробовал написать билд систему на swi-prolog или mercury? По-моему в них есть всё что нужно.
Что думаете, эксперты опеннет?
Сразу отвечаю, я пробовал, но мудрости нехватило. Но я и не самый умный на опеннет:)
Накидайте самое хорошее что есть в autoconf и make, если я этого не учел. Очень интересно. Честно!
Самое хорошее это то, что он есть. На этом, пожалуй, всё.
> Накидайте самое хорошее что есть в autoconf и make, если я этого
> не учел. Очень интересно. Честно!Поддерживает овердохрена систем. По минимуму configure что-то детектит на любой штуке где есть posix shell. Даже на cygwin каком, или msys. Или винтажном юниксе каком. Ему не важно, как минимум он getting it on wheels. А там уже понятнее в какую сторону.
Cmake? В последних версиях подтянули но вообще порой проверки обламываются - и дебажить это не сильно круто.
Месон? Требует электрон^W питон и работает на паре платформ, остальное "нинужна". Хтонически не умеет в мэйкфайлы. С очень дружелюбным ответом что никогда поддерживать не будет.
С cmake все туго. Создание CMakeLists.txt (еще то горбатое названьице), собирающего приложение под линукс и под мингв, требует в разы больше времени, нежели создание отдельных makefil'ов для этих проектов руками. При этом со стопроцентной вероятностью через пять-семь лет этот .txt ничего уже не соберет и придется опять потратить день или два на его отладку, в то время как makefile'ам это по барабану -- через шесть лет, после замены железа и замены FC19 на FC32 все собралось влет.
Мало того, структура генерируемых симейком makefile'ов напоминает структуру исходников из-под фреймворков, написанных на фреймворках, написанных на фреймворках ..., одним словом, ничего в этой каше полупустых файлов не понять и никакой возможности прогнать make вхолостую, чтобы посмотреть, что и с какими ключами будет вызываться.
> То есть, в моем понимании, это должна быть система, наверное, на swi-prolog или mercury,
> где есть центральная база знаний о всех используемых системах, которая подтягивается онлайн,
> во время сборки или по запросу(если нет интернета, например, на CI).Это как раз должно быть исключено безусловно. Сборка проекта должна выполняться строго изолированно без какого-либо доступа в интернет. Достаточно того, что make получает доступ по чтению к файлам системы программирования (заголовки, объектные модули и библиотеки).