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

Сложно обьяснить что там без раскрытия NDA, но это совсем похлеще решение. Я не знаю, это как сравнивать patch.tar.gz и гитхаб

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

а вообще любой декларативный DSL специально спроектированный под задачу, но умеющий императивные вставки или хуки.

Главное, чтобы не на тьюринг-полном.

А JSON/XML/YAML - это, в общем-то, синтаксис, а не семантика.

Чем убог json? Именно для конфигов.

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

Хотя нет, вроде public инфа http://www.youtube.com/watch?v=b52aXZ2yi08

Зачем использовать в новой системе сборки синтаксис уже существующей системы?

Если ты про это, то мой ответ — для стандартизации и упрощения изучения. Новый API изучается проще, чем новый ЯП. Ибо кто знает, какие дерзкие синтаксические конструкции может придумать воспалённое воображение некоторых авторов.

Скажем, я придумал на коленке сейчас:

cc ( source.c ) -> output -> [myprog]

кстати тут ещё важно насколько ты большой проект собирать хочешь, с мелкими, например, прекрасно справляются языкоспецифичные системы сборки типа для haskell - cabal (лучше, чем извращение на makefile в ganeti :)), но с другой стороны чуть становится сложнее, например, пакет состоит из 10 своих либ, часть из которых используют патченные либы третьих сторон, под это дело ещё нужно собирать сишную либу и уметь гонять на ядре со специально обученными модулями и без, при пересборках пересобирать только то, что надо, интегрироваться с ci, и генерить пакеты, уметь делать песочницы под сборку проекта и не косячить при интеференции песочницы и системы. А ещё к этому делу можно deployment тулсы хотеть, типа генераторов строк запуска и т.п.. То уже становится интересно и, например, в кабале проявляется 100500 багов.

Если ты про это

Я про это:

Может проще использовать например Python

Такой подход был многажды опробован и признан негодным.

да и про это тоже:

Главное, чтобы не на тьюринг-полном.

А вот это:

Ибо кто знает, какие дерзкие синтаксические конструкции может придумать воспалённое воображение некоторых авторов.

просто песня. Ты не подумал, какие возможности для воспаленного воображения предоставляют твои JS и Ruby?

А чо, нормально выглядит

Только зачем output, квадратные скобки и прямой порядок?

myprog = cc ( source.c );

Пофиг, но чтобы точно обречь на успех, храни конфиг в MSSQL.

Кстати неплохая идея )

Ты не подумал, какие возможности для воспаленного воображения предоставляют твои JS и Ruby?

Пускай предоставляют. Важно их использовать правильно. На особо упоротых фантастов есть есть codestyle guide.

Ты так и не понял.

гуйня как в visual studio, при том на формат файлов плевать. :)

Давай ты обоснуешь, что нельзя сделать лучше.

Сделать что именно? Синтаксис описания графа зависимостей?

Только зачем output, квадратные скобки и прямой порядок?

Ждал этого вопроса. Вот как раз суть в том, что тебе они кажутся лишними, а мне нет. А имея стандартный язык можно ругаться только на API (а не на синтаксис). Да и в конечном итоге API можно обернуть в более приятные формы.

myprog = cc ( source.c );

Ох, лол :)

Program = function (config) {
    this.name = config.name;
    this.type = config.type;
}

function cc() {
    var out = mktemp();
    system('cc', '-o', out, '--', arguments);

    return new Program({ name: out, type: 'executable' });
}

myprog = cc('source.c');

Ты так и не объяснил. Чисто для разъяснения ситуации: Perl — это write-only язык?

Давай ты обоснуешь, что нельзя сделать лучше.

Сделать что именно?

DSL системы сборки, очевидно же.

Ты так и не объяснил

Ответы были в том, что я процитировал. Если ты их не понял или не поверил - дело твое.

qbs и ant твои друзья, судя по приоритетам в ассоциативном ряду.

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

Идеал - CMake.

Обычных конфигов без логики естественно не хватит. Прикручивать к конфигам логику ничем хорошим не кончается. Python уже был в SCons'е, это неюзабельно, хуже него, пожалуй, только autocrap (что исходник, что нагенерённые из него мегабайты блевотины). qmake в принципе ничего не умеет.

Ничего лучше autoconf и automake человечество пока не придумало :)

Ещё buck интересный проект, но только для Android

Лицоладонь

YAML is new black.

А что не так?

Может быть жесточайшие никому не ведомые велосипеды

sh, M4 и шаблоны Makefile-ов - это велосипеды?

А то что лапша, бойлерплейт, кастомный язык, неинтуитивный синтаксис и генерирует лапшу в make

А то что лапша, бойлерплейт, кастомный язык, неинтуитивный синтаксис и генерирует лапшу в make

Где там кастомный язык, ткни пальцем? Ты про https://ru.wikipedia.org/wiki/Макропроцессор_m4 ?

По мне в исходниках (которые *.ac и *.am) синтаксис вполне интуитивный и читабельный, а сгенерированные файлы для человека не предназначены, не надо туда заглядывать и возмущаться.

бери docx для офиса 2014 не ошибёшься! ;)

Уточни задачу, требования.

Посмотри форматы в /etc, ~/.*

qmake умеет все что нужно, просто все через жопу.

Вполне реально. Я вот несмотря на все терпение не дошел от жопы до «все что нужно»

ну с .pri и, опционально, своими спеками можно навелосипедить то что тебе нужно, но это боль, страдание и «через жопу»

// QtCreator же собирается qmake'ом, как и сами Qt...

json5

вот, система сборки, высокоуровневая, использует json, можно посмотреть примеры, и решить «нравится/ненравится»

https://github.com/Alexey-Yakovenko/deadbeef-plugin-builder/tree/master/plugins

(это не замена автотулс/cmake/waf/make, а надстройка над ними всеми, но в вопросе формата - это непринципиально)

YAML is the new black.

JSON, XML, YAML? Может быть s-выражения?

Только toml-lang, только Мытищи!

у нас один чел на lua делал, но он был реально псих

YAML?

Ты спеку на ямл читал? Говна кусок это.

В чем конкретно?

Чем убог json? Именно для конфигов.

При правке и чтении конфигов путаешься, где какая скобочка что открыла и что закрыла. XML и то читабельнее, как ни удивительно.

cmake хорош

Зачем они нагородили Find* модуль под каждую либу вместо pkg-config?

Нет, pkg-config есть само-собой, но есть некоторые кривые библиотеки, для которых нет pkg-config! Скажем, CUDA!

но есть некоторые

Так вот они вместо некоторых нафигачили модули даже под очень популярные либы

Идеал - CMake.

Там язык описания наркоманский.

В чем конкретно?

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

не везде pkg-config есть.

Где нету?

А какие требования на DSL системы сборки? Проставить цели и их зависимости, привязать к ним нужные действия, подставить нужные костылики? Так ведь всё это и есть в обычном make. Собственно, я и клоню к тому, что на мой взгляд самое разумное - плясать от недостатков классического мейка (но сначала, разумеется, их надо идентифицировать), расширяя его в нужных местах. Возможно, обычной макросистемы поверх вполне хватит (как это есть в случае pkgsrc).

Городить свой язык для решения решенной задачи - это, кхм, неоправданно, чтоли. Всё равно в итоге получится что-то примерно похожее, но убогое и неказистое (согласно 10му правилу Гринспуна).