История изменений

Пока не видел формата, который бы мне понравился. Все убогие. Однозначно не 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> и за доли секунды видишь результат - было бы круто. Возможно стоит компилировать скрипт сборки в бинарник и его запускать, сам скрипт меняется крайне редко. Ну это так, мысли вслух.

Пока не видел формата, который бы мне понравился. Все убогие. Однозначно не 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 это было бы просто превосходно. Столько велосипедов, хотя это всё не нужно по факту, один хороший гибкий инструмент справится со всеми языками, нет в них таких принципиальных отличий, из-за которых надо писать отдельные системы сборки.