Как стать автором
Обновить

Комментарии 10

Если сравнивать с синтаксисом make, то обилие пунктуации оставляет впечатление, что это язык не для людей, а для роботов-парсеров.
Обычный json файл.
Да, теперь понятно где черпали вдохновение разработчики qbs, хотя последний даже посимпатичнее будет и таки собирает сам, а не является генератором.
Начиная читать статью, думал что найду наконец альтернативу CMake с нормальным синтаксисом. Но нет, синтаксис GYP немногим лучше и желание переходить на «экзотический» проект не возникло. Эх и ах…
Я вас полностью поддерживаю. Я не ставил своей целью переубедить людей использовать CMake, я и сам долго колебался, какую из двух систем выбрать для проекта. Мне хотелось показать неплохую альтернативу и, заодно, подготовить публично доступную русскоязычную документацию по проекту (в частности, для моих коллег).
К сожалению, я не нашёл прямого аналога. Вообще возможности конфигурирования в GYP мне показались значительно более скудными, чем у CMake. Фактически, они ограничиваются секцией conditions, позволяя включать/исключать исходный код, флаги компиляции и линковки в зависимости от операционной системы и переменных.

Видимо, авторы GYP нацеливались на self-contained проекты, которые не интегрируются с окружением, а лишь выбирают наиболее подходящую реализацию своего функционала в зависимости от окружения. Но это лишь мои домыслы.
Понятно, спасибо.
И ещё вот такой вопрос: прогрессбар компиляции-то, подобный cmake'у, GYP показывает? :)
Нет, прогрессбара нет :)
Внешний вид процесса компиляции при использовании make-бэкэнда напоминает компиляцию Linux-ядра, судя по генерируемым Make-файлам, техника отображения выполняемых команд позаимствована именно оттуда (она также описана в книжке «Managing Projects with GNU Make» 3ed).
Ясненько.
В общем, останусь при своём мнении: CMake, как кроссплатформенная утилита для сборки крупных проектов, невыносимо отвратителен. Но остальные такого рода утилиты ещё хуже :(
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.