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

Любом готовом, декларативном, предназначенном для этого языке, прикинь? Ты waf изобретаешь или scons? Или просто провоцируешь флейм? На вкус и цвет идеальных систем сборки нет, выбери одну и юзай. А в ней все придумали за тебя, но только правильно.

http://xkcd.com/927/

В autotools как раз велосипедов не использовали.

А конфиг должен быть на чем-то декларативном, но не убогом JSON.

Системы сборки чего?

Если сonfiguration manager, то json или yaml

Любом готовом, декларативном, предназначенном для этого языке, прикинь?

Каком?

Ты waf изобретаешь или scons?

Какая разница?

Или просто провоцируешь флейм?

Какая разница?

Да не, компилялку аля qmake, cmake, autotools, только без онанизма с то хреновой поддержкой pkg-config, то возней с промежуточными этапами, когда тебе дают тупые переменные MYLIB_CFLAGS и ты их сам руками пихаешь если не забудешь

Use QBS, Luke! Может понравится... Там уже более человековый язык для сборки...

YAML?

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

Это уже хоть что-то похожее на нормальную систему. Хотя я и не задавал вопрос «Какую систему сборки использовать мне?»

Гипотетически обсуждаю. А пишу или ковыряю готовую - тайна

Каком?

Каком сказано в документации по выбранной системе сборки.

Но ведь я не выбираю систему сборки, что мне тогда делать?

JSON отлично подходит и для хранения конфигов

LUA

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

Не проектировать свою. Пойти заняться делом.

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

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

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

Гипотетически мне больше всего нравится синтаксис make — наиболее близкий к предметной области. Вообще на нем вполне реально спрятать весь микроменеджмент с флагами и т.п., а в пользовательский Makefile выставить высокоуровневый интерфейс. Пока работал в линуксе, так и делал. Под виндой сейчас использую cmake, синтаксис не так крут, но из коробки намного меньше микроменеджмента.

YAML ещё худшее говно, чем JSON.

Если ты пишешь систему сборки, велосипедь свой язык. Как минимум это поможет тебе понять задачу. Если не знаешь, с чего начать, погугли Vesta software description language.

Только после выяснения того, что его пост является чистым 4.3 и не содержит вопроса. Это очень «терпеливо» по современным стандартам интернет-общения, в т.ч. местным.

Пишешь-пишешь свою. Ну проектируешь. Тут может быть только твое диктаторское мнение о том, что правильно, игры в демократию точно не дадут тебе написать чего-то заметно годного. Пользуй чужие, получай опыт, вырабатывай мнение.

Python может производить структуры данных, он может их просто вычислить и потом например с определенным ключем они могут быть выведены в JSON. А там и IDE

Ну я же не Поттеринг чтобы кого-то заставлять чем то пользоваться. А писать я могу что угодно до потери пульса. Не вижу причин нервничать

Rust`овский Cargo использует toml: http://crates.io/manifest.html . Жить вполне можно, хотя toml и странноватый какой-то.

велосипедь свой язык

Не имею малейшего желания

Потом ты в IDE нажал «Add file to project», и что IDE должна сделать?

Ничего, обычно системы сборки смотрят на папку или wildcard папок. Потому просто, если надо, reevaluate если система сборки должна выдать инфу по файлу, его ключи сборки.

Поттеринг тоже писал до потери пульса, отлично проектировал софт, никого не заставлял им пользоваться — а ему на киллера скидываться начали. Давай-давай, будем вместе нервничать.

Если ты пишешь систему сборки, велосипедь свой язык

Но зачем? Makefile - вполне себе готовый язык для описания зависимостей задач. PKGSRC, который из себя представляет набор макросов для make, вполне себе работает и вполне себе декларативен.

Не будем о грустном. Такую лапшу еще поискать. Хотя их тоже можно понять, писали абсолютно универсальную вещь

Если ты пишешь систему сборки, велосипедь свой язык

Но зачем?

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

велосипедь свой язык

Не имею малейшего желания

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

Поттеринг тоже писал до потери пульса, отлично проектировал софт, никого не заставлял им пользоваться — а ему на киллера скидываться начали. Давай-давай, будем вместе нервничать.

Так деньги собирают? Я реально пожертвую рублей 200-300...

y not?

Makefile вполне себе наглядно иллюстрирует задачи и их зависимости. Нагляднее, наверное, некуда

y not?

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

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

app run

Потом в vim поменять код, сохраниться, но следующий app run пусть будет моментальным, так как оно уже все пересобрало в момент сохранения

Внимательно прочитал ответ, но так и не понял, на что именно ты ответил.

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

угадай гугловца по треду.

// Система сборки должна быть на shake (http://hackage.haskell.org/package/shake)

Это просто моя тяга к приключениям. В гугле уже поинтереснее вещей написали, я не осилю такое

Ну, если ты делаешь систему сборки Gtk-приложения на домашней тачке, тогда конечно.

Лол, забавная формулировка. Но я просто понял что я задолбался писать cmake портянки и возиться этими комбайнами. Писать себе софт очень оправдывает себя. Я как минималист обычно пользуюсь малой частью фич софта и они реализованы как говно. Потому лисапедить себе потоковые аудиоплеер с ВК было проще чем ругать всякие амароки или ритмбоксы

Groovy крут (Gradle). В основном пишешь в декларативном стиле и проявляешь гибкость, где надо, используя императивщину.

В моём идеальном мире конфиг системы сборки должен быть на JS: в простом случае JSON, в сложном — код на JS.

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

то-то от них веселые истории про системы сборки и ад с этим связанный слышишь :). Там какая-то адская жесть поверх make?

Если ты пишешь систему сборки, велосипедь свой язык.

Ну и зачем оно нужно? Помимо изучения API еще изучать и язык. Лишние сложности.

Я за использования ЯП, которые уже известны и используются, как DSL (JS, Groovy, Ruby).

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

Java-based системы сборки как раз страдают от долгого время старта.

So true. Короче, мой посыл был: используй уже существующие DSL. Просто создай удобное API для них.

Я за использования ЯП, которые уже известны и используются, как DSL (JS, Groovy, Ruby).

Да, да... выше по треду уже ответили.

Цитата из «Золотого теленка» была бы в тему.