На каком языке должен быть формат конфига системы сборки?

содержательная часть (human-readable форматирование) не специфицирована

Напишу детальнее, что я имею ввиду.

http://www.yaml.org/spec/1.2/spec.html#id2762313

Presenting the Serialization Tree

The final output process is presenting the YAML serializations as a character stream in a human-friendly manner. To maximize human readability, YAML offers a rich set of stylistic options which go far beyond the minimal functional needs of simple data storage. Therefore the YAML processor is required to introduce various presentation details when creating the stream, such as the choice of node styles, how to format scalar content, the amount of indentation, which tag handles to use, the node tags to leave unspecified, the set of directives to provide and possibly even what comments to add. While some of this can be done with the help of the application, in general this process should be guided by the preferences of the user.

То есть спека допускает тучу альтернативных вариантов форматирования («stylistic options») для одного и того же контента. И ничего не говорит о том, какой из вариантов в каждом конкретном случае позволяет maximize human readability.

YAML по сути не обеспечивает никакого human-friendly, а целиком и полностью спихивает эту ответственность на конкретные реализации YAML-процессоров (типа, пусть тащат под капотом пачку доморощенных эвристик для условно-адекватного выбора stylistic options), либо даже на приложения которые используют YAML-процессор (типа, пусть попытаются правильно настроить эвристики процессора).

Ну и на кой ляд мне сдались эти пляски с бубном?

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

Линк по теме: https://github.com/mk-fg/pretty-yaml

Во-первых, как должны IDE такое парсить?

Как-то же парсит IDEA Gradle. И как-то добавляет зависимости и файлы прямо в скрипты.

Во-вторых, надобно отделять описание от деталей реализации. Кто не понимает, зачем, тому ещё рано обсуждать системы сборки и разработку софта вообще

А ты попробуй, расскажи. Ты же понимаешь, зачем?

на том же, что и код, который собираешь

да, я про сбт. он не сложный, а гибкий (с)

premake4

чего-то автотулз-срач разжечь не удалось, а я так старался :) хнык-хнык

Ну и как cmake? Полное г? :-) Я после make ничччего не понял :-) Сейчас модно переходить на новые системы сборки вроде grunt, gradle, cmake, но кажется, что старый make вполне годная штука для малых и средних проектов.

Будь Ъ и прочитай мануалы autoconf и automake, там истинный юникс-вей :)

Пока не видел формата, который бы мне понравился. Все убогие. Однозначно не XML/JSON и тому подобные стандартные форматы. Это просто лень писать лексический разбор и она ничем не оправдана в случае серьёзного проекта.

Попробую сформулировать свои мысли.

С одной стороны мне нравится maven в плане декларативности. Декларативность идеальна для типичных проектов, в которых нет изысков и которые собираются стандартными путями. Хорошая система сборки обязательно должна быть декларативна.

С другой стороны достаточно часто бывает нужно закодировать какой-то примитивный алгоритм. И в декларативном виде (особенно в каком-нибудь XML-е) можно просто идти и вешаться. Это абзац. Обязательно должна быть возможность использовать нормальный полноценный язык программирования в нужном месте. И желательно не экзотический, а что-нибудь вроде JS или LUA.

На первый взгляд неплохо выглядит идея использовать готовый язык программирования и создать набор функций, имитирующих DSL. Например так сделаны Grunt, sbt. На практике получается плохо. Совершенно неуместные ограничения, от которых можно было бы избавиться, если бы был свой формат. Возможно есть языки, на которых это получится.

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

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

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

В качестве универсального языка отлично подходит JavaScript. Он хоть и имеет кучу недостатков, но фатальных среди них нет, а если взять какой-нибудь ES6, то в целом неплохой язык получается.

Если бы эта система сборки умела собирать потенциально всё и иметь универсальную систему зависимостей для любого языка, java, c, c++, python, javascript, perl это было бы просто превосходно. Столько велосипедов, хотя это всё не нужно по факту, один хороший гибкий инструмент справится со всеми языками, нет в них таких принципиальных отличий, из-за которых надо писать отдельные системы сборки.

И последний момент - она должна работать быстро. Вообще системы сборки очень медленные и я не понимаю, почему. Запускаешь maven, там делать нечего, но он несколько секунд жужжит. Компилятор джавы работает долю секунды, тесты пролетают за долю секунды, а весь билд секунд 5-10 работает. Вот работал бы он как make - набрал команду, жмякнул <Enter> и за доли секунды видишь результат - было бы круто. Возможно стоит компилировать скрипт сборки в бинарник и его запускать, сам скрипт меняется крайне редко. Ну это так, мысли вслух.

Хинди.

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

make + scheme

А какие требования на DSL системы сборки?

Ты от меня ещё эскизный проект потребуй. Если что, это не я хочу написать систему сборки.

Возможно, обычной макросистемы поверх вполне хватит (как это есть в случае pkgsrc).

Возможно. Но даже «макросистема поверх» - это новый язык.

Всё равно в итоге получится что-то примерно похожее

Волшебное слово «примерно». Ну да, CMake или Vesta SDL похожи на make. Примерно.

но убогое и неказистое (согласно 10му правилу Гринспуна).

В результате, конечно, может получиться говно, только это закон Старджона. Правило Гринспена здесь не причём.

Хинди

Санскрит же, ну.

Мне в мавене не хватает более настраиваемого резолва зависимостей. Пример, как сделать так, чтобы все транзитивные зависимости от commons-logging заменялись на jcl-over-slf4j? А никак, либо эксклюдь у каждой зависимости по отдельности этот commons-logging, либо используй gradle.

Вообще, все системы сборки под JVM - днище, но gradle из них самая съедобная.

Универсальная система сборки? Получится страшный, неудобный монстр, в любом случае проигрывающий специализированным решениям.

Пример из мира JVM: sbt удобнее для Scala-проектов, чем мавен, хотя бы потому что учитывает бинарную совместимость между Scala-библиотеками. В мавене тебе придётся за этим следить самому.

Ну и как cmake? Полное г? :-) Я после make ничччего не понял :-) Сейчас модно переходить на новые системы сборки вроде grunt, gradle, cmake, но кажется, что старый make вполне годная штука для малых и средних проектов.

Не знаю, что там можно не понять, я его осилил за десять минут. В использовании очень удобен, из коробки умеет гораздо больше make.

Чем это он наркоманский? Наркоманство - это блоки отступами, скобки лиспа и dnl в m4. А здесь обычные функции() и make'овские ${переменные} - ничего более удобного и привычного и придумать нельзя.

Универсальная система сборки? Получится страшный, неудобный монстр, в любом случае проигрывающий специализированным решениям.

Почему ты так думаешь?

Пример из мира JVM: sbt удобнее для Scala-проектов, чем мавен, хотя бы потому что учитывает бинарную совместимость между Scala-библиотеками. В мавене тебе придётся за этим следить самому.

Этот пример значит только то, что maven проектировался исключительно для Java и его создатель даже не подозревал про Scala и бинарную совместимость, когда продумывал его.

Изобрази средней сложности Makefile на JSON - поймешь.

Я тут недавно переводил с gyp на cmake.
Так на cmake как то более громоздко выглядит.
Кстати доку по gyp читать не пришлось, все достаточно понятно и так.

Изобрази средней сложности Makefile на JSON - поймешь.

Я тут недавно переводил с gyp на cmake.
Так на cmake как то более громоздко выглядит.

Сравнивать с эталонно угребищным языком CMake нечестно :)

Кроме того, если взять gyp - в нем можно описывать свои правила сборки артефактов? Допустим, мне нужно собрать initramfs или еще что-то нестандартное.

Чем это он наркоманский?

Ну, например оператор присваивания.

SET(FOO bar)

Не foo=bar, не set foo bar, не set(foo, bar).

А здесь обычные функции()

Вот это:

TRY_RUN(SHARED_LIBRARY_PATH_TYPE SHARED_LIBRARY_PATH_INFO_COMPILED
        ${PROJECT_BINARY_DIR}/CMakeTmp
        ${PROJECT_SOURCE_DIR}/CMake/SharedLibraryPathInfo.cxx
        OUTPUT_VARIABLE OUTPUT
        ARGS "LDPATH")

ни разу не обычный вызов функции с именованными параметрами. Это вызов функции с именованными параметрами в языке, придуманном умственно отсталыми наркоманами.

make'овские ${переменные}

Переменные в make пишутся $(переменная).

Сравнивать с эталонно угребищным языком CMake нечестно :)

Если бы я все это на чистый make переводил, то было бы еще грустнее, т к gyp умеет билдить под разные платформы разными компилерами. Аналог на make был бы просто огромен.

Кроме того, если взять gyp - в нем можно описывать свои правила сборки артефактов?

ХЗ, я ни разу не знаток gyp. Я просто перевел )
Емнип сам gyp на питоне и питоном его как то можно расширять.

Как-бэ основной посыл был в том, что я таки аж ни разу не фанат JSONa, но как показала практика, файл проекта на JSONоно подобном синтаксисе выглядит совсем не страшно, а скорее даже наоборот.

Как-бэ основной посыл был в том, что я таки аж ни разу не фанат JSONa, но как показала практика, файл проекта на JSONоно подобном синтаксисе выглядит совсем не страшно, а скорее даже наоборот.

Насколько я понимаю, gyp -это просто параметризованный генератор проектов для разных сред. Понятно, что задавать параметры можно и JSON, но когда потребуется что-то сложное - добро пожаловать в Python. Не вижу преимуществ по сравнению с make (у GNU Make хотя бы есть встроенный скриптовый язычок).

Ну а пока потребности хорошо укладываются в возможности инструмента, JSON будет не намного хуже того же make.

http://stackoverflow.com/questions/15709/is-this-valid-yaml

In general YAML is concise and human readable / editable, but not really human writable, so you should always use libraries to generate it.

Чем это он наркоманский?

По треду выше уже ответили. Возможности CMake действительно впечатляют, если бы запилили к нему альтернативный язык описания (как я уже отмечал: можно JS) и цены б ему не было.

make'овские ${переменные}

Переменные в make пишутся $(переменная).

https://www.gnu.org/software/make/manual/html_node/Reference.html

Я однажды где-то подсмотрел и всегда использовал ${переменная} и $(функция), просто для наглядности.

«Альтернативный язык описания» опять напоминает мне SBT. Это когда делают два языка, а потом по всему инету примеры для плагинов то на одном, то на другом. И традиционно не на том, на котором пишешь ты

«Альтернативный язык описания» опять напоминает мне SBT. Это когда делают два языка, а потом по всему инету примеры для плагинов то на одном, то на другом. И традиционно не на том, на котором пишешь ты

Коварный план состоит в том, чтоб постепенно популяризировать один и задепрекейтить другой. От легаси, увы, быстро не избавишься

ничего более удобного и привычного и придумать нельзя
cmake

норкоман детектед

скобочка что открыла и что закрыла

Ну это как с лиспом — со временем привыкаешь. К тому же, во многих редакторах есть подсветка разных парных елементов.

Ну, например оператор присваивания

И в чём проблема? Букв не намного больше, синтаксис получается более однородным, удобно писать многострочные присваивания (а оно нужно очень часто), также там есть опции которые часто нужно использовать и в противном случае для них потребовался бы отдельный синтаксис.

ни разу не обычный вызов функции с именованными параметрами. Это вызов функции с именованными параметрами в языке, придуманном умственно отсталыми наркоманами.

Ну такую аргументацию и оспаривать не нужно. Нормальный синтаксис, обязательные позиционные + необязательные именованные параметры, это очень удобно.

Переменные в make пишутся $(переменная)

Не правда:

To substitute a variable’s value, write a
dollar sign followed by the name of the variable
in parentheses or braces: either ‘$(foo)’ or
‘${foo}’

И в чём проблема?

В том, что синтаксис наркоманский.

Нормальный синтаксис

Если употреблять те же наркотики...

Полностью солидарен, отвращение вызывает

QBS.

Остальное жутчайшие костыли, особенно legacy-autotools и CMake.