| |
| |
| 3.11, Аноним (11), 12:51, 29/01/2021 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +2 +/– |
Цмейк дрянь мерзопакостная. Месон получше, но тоже гадость. Когда уже придумают нормальную альтернативу автотулсам.
| | |
| |
| |
| 5.15, Аноним (11), 13:19, 29/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Это уже вообще треш, особенно наверно premake. Поэтому я и говорю, что meson довольно неплох ещё, в сравнении с тем, что существует помимо него.
| | |
| |
| |
| 7.17, Аноним (11), 13:27, 29/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Зачем генератору мейкфайлов си? Из того что я видео, самые трешовые ограниченные и забагованные поделки были на bison (т.е. вполне себе си), а проблемы не исправлялись десятилетиями. Чем меньше си в этом вопросе, тем лучше, тут всего-то нужно собрать файл под определённые конфигурацию и платформу, что может быть проще.
| | |
|
|
|
| |
| 5.43, Аноним (43), 17:55, 30/01/2021 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +/– | |
>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.
| | |
| |
| 6.47, омоним (?), 08:52, 31/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
> Но зачем, если CMake сама генерирует ninja.build?
Потому что gn генерирует намного быстрее CMake.
Иногда собираю всё из LLVM, поэтому заметил.
| | |
|
| 5.54, Аноним (-), 21:16, 31/01/2021 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– | |
> llvm-project потихоньку переходит на gn+ninja
Ну кто бы сомневался.
> Не думаю.
Просто эту пакость гугол малость сожрал. Ну вот и переваривать начал понемногу. Теперь будет чудная либа для обслуг нужд гугли. А, еще слегка эппла, они вроде слегка примазались.
| | |
|
| |
| 5.25, Аноним (11), 15:25, 29/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
> Дрянью является тот кто считает другое дрянью.
Мразью является тот, кто анонимно оскорбляет незнакомых людей в интернете. Парируйте.
| | |
|
|
|
|
| 1.27, bzz (?), 16:42, 29/01/2021 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +2 +/– | |
почитайте доки к аутоконф. Веселое чтиво, рекомендую.
> 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/autoconf-2.70/autoc
| | |
| |
| 2.39, Ordu (ok), 02:58, 30/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| –2 +/– |
 > The primary goal of Autoconf is making the user’s life easier; making the maintainer’s life easier is only a secondary goal.
Хыхы, да. Верно подмечено. Именно поэтому разработчики и заменяют autoconf на альтернативы.
| | |
| |
| 3.51, adolfus (ok), 19:57, 31/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
 Те, кто запускает автотулс, являются пользователями [автотулса]
Это же справедливо и для SQL -- все, кто составляют SQL-выражения, являются пользователями [базы данных] -- SQL сделан для пользователей, а ISAM -- для программистов SQL.
| | |
|
|
| |
| 2.45, Аноним (43), 17:59, 30/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– |
Я жду как праздник новости о том, что дистры сговорились и выпилили весь софт, использующий autotools, из репозиториев.
| | |
| |
| 3.55, Аноним (-), 21:18, 31/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> Я жду как праздник новости о том, что дистры сговорились и выпилили
> весь софт, использующий autotools, из репозиториев.
Я бы станцевал на твоей могилке. Это был бы праздник.
| | |
|
|
| 1.32, анонимуслинус (?), 00:42, 30/01/2021 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| –1 +/– |
эх а раньше писали в текстовиках и компилили gcc. прогресс на всю голову. я понимаю попытка ускорить, но походу только усложняют и запутывают. причем себя в том числе. потом ловят вечные cve или баги несовместимости то с одним , то с другим.
| | |
| 1.35, souryogurt (ok), 01:29, 30/01/2021 [ответить] [﹢﹢﹢] [ · · · ] [↑] [к модератору]
| +/– |
 Мне лично нравится и 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? По-моему в них есть всё что нужно.
Что думаете, эксперты опеннет?
| | |
| |
| |
| 3.56, Аноним (-), 21:21, 31/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> Накидайте самое хорошее что есть в autoconf и make, если я этого
> не учел. Очень интересно. Честно!
Поддерживает овердохрена систем. По минимуму configure что-то детектит на любой штуке где есть posix shell. Даже на cygwin каком, или msys. Или винтажном юниксе каком. Ему не важно, как минимум он getting it on wheels. А там уже понятнее в какую сторону.
Cmake? В последних версиях подтянули но вообще порой проверки обламываются - и дебажить это не сильно круто.
Месон? Требует электрон^W питон и работает на паре платформ, остальное "нинужна". Хтонически не умеет в мэйкфайлы. С очень дружелюбным ответом что никогда поддерживать не будет.
| | |
| |
| 4.60, adolfus (ok), 20:20, 01/02/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
С cmake все туго. Создание CMakeLists.txt (еще то горбатое названьице), собирающего приложение под линукс и под мингв, требует в разы больше времени, нежели создание отдельных makefil'ов для этих проектов руками. При этом со стопроцентной вероятностью через пять-семь лет этот .txt ничего уже не соберет и придется опять потратить день или два на его отладку, в то время как makefile'ам это по барабану -- через шесть лет, после замены железа и замены FC19 на FC32 все собралось влет.
Мало того, структура генерируемых симейком makefile'ов напоминает структуру исходников из-под фреймворков, написанных на фреймворках, написанных на фреймворках ..., одним словом, ничего в этой каше полупустых файлов не понять и никакой возможности прогнать make вхолостую, чтобы посмотреть, что и с какими ключами будет вызываться.
| | |
|
|
| 2.59, adolfus (ok), 19:55, 01/02/2021 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
> То есть, в моем понимании, это должна быть система, наверное, на swi-prolog или mercury,
> где есть центральная база знаний о всех используемых системах, которая подтягивается онлайн,
> во время сборки или по запросу(если нет интернета, например, на CI).
Это как раз должно быть исключено безусловно. Сборка проекта должна выполняться строго изолированно без какого-либо доступа в интернет. Достаточно того, что make получает доступ по чтению к файлам системы программирования (заголовки, объектные модули и библиотеки).
| | |
|
|
