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

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

А при чем тут это? Автор просто показал возможности cmake, как я понял. Просто позабавился немного.
Круто:) Но всё равно они(kitware) гады, что запилили свой язык, вместо чего нибудь популярного и легко разбираемого сторонними утилитами — того же js.
Почему вы думаете что свой язык чем-то хуже любого существующего и/или что существующий язык способен эффективно решать все возможные проблемы так что его нужно использовать и в системе сборки? Системы сборки с существующими языками (m4, python) мы уже видели, они отвратительны.
еще Fake
Было бы хуже, если вместо

function (clrscr)
file(WRITE /dev/stdout "${ESCAPE}[2J")
endfunction(clrscr)

Было бы

function clrscr() { stdout.write(escape + «2J») }?

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

— Нормальное раскрытие переменных а-ля make (message(«Building ${FOO} with ${BAR}» вместо плясок с кавычками и плюсами)
— В том числе рекурсивное (${FOO_${BAR}}) которое иначе потребовало бы запаковку значений в словари и обратно
— Отсутствие необходимости писать кавычки почти везде
— Нормальный foreach по содержимому массива
— Форсирование повторения условия в endif/endfor/end* что сильно увеличивает читабельность
— Именованные аргументы на мой взгляд сделаны очень удобно
— Правильная передача значений в дочерние CMakeLists.txt и обратно (PARENT_SCOPE)
— Кэшированные переменные и все их атрибуты
— Макросы
То есть нужен язык со string interpolation, foreach, именованными аргументами, подобием модульности и без кавычек?

Вот эти фичи мне кажутся сомнительныими:

— В том числе рекурсивное (${FOO_${BAR}}) которое иначе потребовало бы запаковку значений в словари и обратно

Если использовать чем это лучше чем ${foo.bar}

— Форсирование повторения условия в endif/endfor/end* что сильно увеличивает читабельность

Нет ли способа так увеличивать читабельность, чтобы это не понадобилось?

— Макросы

Мне кажется, в динамических языках это не так сильно нужно.

А вот это я не понял:
— Кэшированные переменные и все их атрибуты

В любом случае нельзя ли взять наиболее подходящий ЯП общего назначения и внести необходимые дополнения туда?
>А вот это я не понял:
— Кэшированные переменные и все их атрибуты

Это уже тонкости реализации, CMake складывает уже вычисленные переменные в бд(кэш) и не вычисляет их до тех пор, пока их не удалить из кэша, или не изменить им значиение насильно.

В любом случае, такое можно сделать на чём угодно, так что относить сиё к поинтам языка CMake — слегка странно, это просто фича.
> То есть нужен язык со string interpolation, foreach, именованными аргументами, подобием модульности и без кавычек?

Нет, нужен DSL на котором удобно писать скрипты сборки. Собственно, такой и получился.
Ваша реплика выглядит странно. Мы как раз и выясняем в чем отличие «DSL на котором удобно писать скрипты сборки» от языка общего назначения (вернее, если обойтись eDSL нельзя ли скомпенсировать недостаток заточенности под задачу выгодами от лучшей поддержки).

Я взял подмножество ваших требований а вы его отрицаете словом нет, не добавляя ясности.

К тому же я задал вопрос «В любом случае нельзя ли взять наиболее подходящий ЯП общего назначения и внести необходимые дополнения туда?»

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

> Ваша реплика выглядит странно

Нет, странно выглядит то что вы несколько примеров нужных фич языка оформили как полное ТЗ. Я вас поправил.

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

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

image

зачем если нужен велосипед, выпиливать его из самолёта

Поюзать самолетную инфраструктуру.

в плане синтаксиса ничего нового не изобретено

А вот это function (name) откуда взято?
Сделать ограниченый DSL на js, или том же python, не является особой проблеммой, оба интерпретатора имеют кучу открытых и легко кастомизируемых реализаций. При этом не надо будет учить новый язык, и писать новый парсер.

Вот тот же OpenSCAD, у них опять же свой язык, но зачем — непонятно, ограничения без какой либо необходимости. Проект опенсурсный и бесплатный, может автор просто хотел свой интерпретатор написать, чисто как упражнение? Единственное предположение — нижележащий язык это ассемблер, и это представление наиболее эффективно для данной предметной области. Но опять же, вряд ли оно сильно выигрывает у asm.js.

Заточить js интерпретатор под свои нужды — крайне не сложно. Что характерно, находятся товарищи которые делают например так :)
Системы сборки которые отвратительны, таковы не из-за языка. В CMake мощная концепция метасборщика, удачно сочетается с модульной системой поиска всего и вся. Однако, имеется определённый порог вхождения, отсутсвие или слабая выразительность многих привычных языковых средств.

Сильно сомневаюсь что можно найти, хоть какой то код на CMake, который будет выглядеть проще и лаконичнее чем аналог на любой распостранёной скриптоте общего назначения. Отсюда — не ясен профит создания и поддержки нового языка (если только это не vendor lock).

Я уже молчу про то, что если бы это был например js, то встроить поддержку CMake в ваше любимое IDE заняло бы пару дней у плохо обученного школьника (и без костылей типа парсинга cbp файла).
> Однако, имеется определённый порог вхождения, отсутсвие или слабая выразительность многих привычных языковых средств.

Это «отсутсвие или слабая выразительность» для системы сборки — как мана небесная, поскольку на cmake всё-таки собирают проекты, а не часы рисуют. Для этого выразительности не только хватает — её столько, что многие вещи сильно упрощаются, а писать хитровыгнутые конструкции желание пропадает. Я достаточно насмотрелся на SCons'овские скрипты от питонистов, которые во всю используют «привычные языковые средства» — разбираться в этом невозможно. Как результат, порог вхождения как раз намного ниже, чем если бы использовался язык общего назначения.

> Сильно сомневаюсь что можно найти, хоть какой то код на CMake, который будет выглядеть проще и лаконичнее чем аналог на любой распостранёной скриптоте общего назначения.

Как-бы DSL всегда быть проще и лаконичнее языков общего назначения. Несколько примеров я привёл выше.

> то встроить поддержку CMake в ваше любимое IDE

Да, давайте выбирать язык для системы сборки на основании лёгкости встраивания его в моё любимое IDE. Да и про лёгкость я бы поспорил — если и понадобится глубокий разбор cmake, то пожалуй проще будет разобрать его синтаксис, чем js, где нужное определение цели возможно придётся вытаскивать через несколько замыканий.
Однако, никто, пока что, так и не встроил CMake в ide, без костылестроения :) Если только JetBrains (надо бы потыкать).

Вот тот же qbs, можно без проблем встроить куда душа попросит, и я не сказал бы что там какой то адский синтаксис, жалко вот он сам собирает (как и упомянутый вами SCons), то бишь относится слегка к другому классу инструментов.

> Это «отсутсвие или слабая выразительность» для системы сборки — как мана небесная, поскольку на cmake всё-таки собирают проекты, а не часы рисуют.

По мимо сборки, на средних и больших проектах встречается ещё ряд задач, как то покрытие кода разного уровня тестами, различные виды анализа кодовой базы (часто специфичные для проекта), кодогенерация и прочие плюшки. В таком случае одна фигня приходится делать find_package(Python REQUIRED) и забавляться с кастомными целями, либо обрастать платформозависимым шелом.
Кто это «мы» видели?
И причем тут языки программирования?
Новый язык нафик не нужен, потому что есть C++, Java, их и так 100500. что мешает хотя бы C использовать вместо непонятного и ущербного cmake 2.8? Нахрена изучать новую матчасть, нахрена заставлять людей мучиться и себя тоже?
Лень арифметику указателей имплементировать?
Возьми стандарт ECMA Script, например готовый QtScript из того же Qt, там уже все реализовано, вставь в свой CMake и нечего какие то непонятные языки-велосипеды изобретать.
Если я бы был инвестором — послал бы нахрен этих изобретателей cmake 2.8, но Cmake ведь бесплатный.
QBS. QML + js. Недостатки определённо у нее есть, но я еще не слышал, чтобы хоть кто-то назвал её «отвратительной».
Я пока не видел ни одного проекта её использующего.
А зачем управляющие последовательности терминала-то хардкодить? Вызовите tput — ровно так же, как вы делаете для date. Что-то типа:

execute_process(COMMAND "tput" "clear" OUTPUT_VARIABLE terminal_clrscr)
function (clrscr)
    file(WRITE /dev/stdout "${terminal_clrscr}")
endfunction(clrscr)
Тут 2 причины:
1) В идеале хотелось максимально решить все средствами cmake без запуска внешних процессов (жаль время узнать не удалось)
2) Я не так давно являюсь пользователем linux и просто не знал про tput

А так да, спасибо за замечание :)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.