Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 22
похвально, но есть же clockywock.
кстати буду благодарен если кто подскажет где его взять под ubuntu
кстати буду благодарен если кто подскажет где его взять под ubuntu
Круто:) Но всё равно они(kitware) гады, что запилили свой язык, вместо чего нибудь популярного и легко разбираемого сторонними утилитами — того же js.
Почему вы думаете что свой язык чем-то хуже любого существующего и/или что существующий язык способен эффективно решать все возможные проблемы так что его нужно использовать и в системе сборки? Системы сборки с существующими языками (m4, python) мы уже видели, они отвратительны.
еще Fake
Было бы хуже, если вместо
function (clrscr)
file(WRITE /dev/stdout "${ESCAPE}[2J")
endfunction(clrscr)
Было бы
function clrscr() { stdout.write(escape + «2J») }?
В чем преимущество своего непохожего языка сдесь?
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)
— Кэшированные переменные и все их атрибуты
— Макросы
— Нормальное раскрытие переменных а-ля 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* что сильно увеличивает читабельность
Нет ли способа так увеличивать читабельность, чтобы это не понадобилось?
— Макросы
Мне кажется, в динамических языках это не так сильно нужно.
А вот это я не понял:
— Кэшированные переменные и все их атрибуты
В любом случае нельзя ли взять наиболее подходящий ЯП общего назначения и внести необходимые дополнения туда?
Вот эти фичи мне кажутся сомнительныими:
— В том числе рекурсивное (${FOO_${BAR}}) которое иначе потребовало бы запаковку значений в словари и обратно
Если использовать чем это лучше чем ${foo.bar}
— Форсирование повторения условия в endif/endfor/end* что сильно увеличивает читабельность
Нет ли способа так увеличивать читабельность, чтобы это не понадобилось?
— Макросы
Мне кажется, в динамических языках это не так сильно нужно.
А вот это я не понял:
— Кэшированные переменные и все их атрибуты
В любом случае нельзя ли взять наиболее подходящий ЯП общего назначения и внести необходимые дополнения туда?
>А вот это я не понял:
— Кэшированные переменные и все их атрибуты
Это уже тонкости реализации, CMake складывает уже вычисленные переменные в бд(кэш) и не вычисляет их до тех пор, пока их не удалить из кэша, или не изменить им значиение насильно.
В любом случае, такое можно сделать на чём угодно, так что относить сиё к поинтам языка CMake — слегка странно, это просто фича.
— Кэшированные переменные и все их атрибуты
Это уже тонкости реализации, CMake складывает уже вычисленные переменные в бд(кэш) и не вычисляет их до тех пор, пока их не удалить из кэша, или не изменить им значиение насильно.
В любом случае, такое можно сделать на чём угодно, так что относить сиё к поинтам языка CMake — слегка странно, это просто фича.
> То есть нужен язык со string interpolation, foreach, именованными аргументами, подобием модульности и без кавычек?
Нет, нужен DSL на котором удобно писать скрипты сборки. Собственно, такой и получился.
Нет, нужен DSL на котором удобно писать скрипты сборки. Собственно, такой и получился.
Ваша реплика выглядит странно. Мы как раз и выясняем в чем отличие «DSL на котором удобно писать скрипты сборки» от языка общего назначения (вернее, если обойтись eDSL нельзя ли скомпенсировать недостаток заточенности под задачу выгодами от лучшей поддержки).
Я взял подмножество ваших требований а вы его отрицаете словом нет, не добавляя ясности.
К тому же я задал вопрос «В любом случае нельзя ли взять наиболее подходящий ЯП общего назначения и внести необходимые дополнения туда?»
Грубо говоря, если нужно сделать свой велосипед, почему бы не использовать хотя бы стандартные гайки.
Я взял подмножество ваших требований а вы его отрицаете словом нет, не добавляя ясности.
К тому же я задал вопрос «В любом случае нельзя ли взять наиболее подходящий ЯП общего назначения и внести необходимые дополнения туда?»
Грубо говоря, если нужно сделать свой велосипед, почему бы не использовать хотя бы стандартные гайки.
> Ваша реплика выглядит странно
Нет, странно выглядит то что вы несколько примеров нужных фич языка оформили как полное ТЗ. Я вас поправил.
> Грубо говоря, если нужно сделать свой велосипед, почему бы не использовать хотя бы стандартные гайки
Если уж опускаться до аналогий, то зачем если нужен велосипед, выпиливать его из самолёта? А стандартных гаек там достаточно — в плане синтаксиса ничего нового не изобретено.
Нет, странно выглядит то что вы несколько примеров нужных фич языка оформили как полное ТЗ. Я вас поправил.
> Грубо говоря, если нужно сделать свой велосипед, почему бы не использовать хотя бы стандартные гайки
Если уж опускаться до аналогий, то зачем если нужен велосипед, выпиливать его из самолёта? А стандартных гаек там достаточно — в плане синтаксиса ничего нового не изобретено.
Ну вот я и интересуюсь, какие фичи языка вы считаете нужными и почему? Еще пришла идея, что можно использовать в качестве хост языка какой-нибудь готовый шелл. Вроде там примерно те же требования
зачем если нужен велосипед, выпиливать его из самолёта
Поюзать самолетную инфраструктуру.
в плане синтаксиса ничего нового не изобретено
А вот это function (name) откуда взято?
зачем если нужен велосипед, выпиливать его из самолёта
Поюзать самолетную инфраструктуру.
в плане синтаксиса ничего нового не изобретено
А вот это function (name) откуда взято?
Сделать ограниченый DSL на js, или том же python, не является особой проблеммой, оба интерпретатора имеют кучу открытых и легко кастомизируемых реализаций. При этом не надо будет учить новый язык, и писать новый парсер.
Вот тот же OpenSCAD, у них опять же свой язык, но зачем — непонятно, ограничения без какой либо необходимости. Проект опенсурсный и бесплатный, может автор просто хотел свой интерпретатор написать, чисто как упражнение? Единственное предположение — нижележащий язык это ассемблер, и это представление наиболее эффективно для данной предметной области. Но опять же, вряд ли оно сильно выигрывает у asm.js.
Заточить js интерпретатор под свои нужды — крайне не сложно. Что характерно, находятся товарищи которые делают например так :)
Вот тот же OpenSCAD, у них опять же свой язык, но зачем — непонятно, ограничения без какой либо необходимости. Проект опенсурсный и бесплатный, может автор просто хотел свой интерпретатор написать, чисто как упражнение? Единственное предположение — нижележащий язык это ассемблер, и это представление наиболее эффективно для данной предметной области. Но опять же, вряд ли оно сильно выигрывает у asm.js.
Заточить js интерпретатор под свои нужды — крайне не сложно. Что характерно, находятся товарищи которые делают например так :)
Системы сборки которые отвратительны, таковы не из-за языка. В CMake мощная концепция метасборщика, удачно сочетается с модульной системой поиска всего и вся. Однако, имеется определённый порог вхождения, отсутсвие или слабая выразительность многих привычных языковых средств.
Сильно сомневаюсь что можно найти, хоть какой то код на CMake, который будет выглядеть проще и лаконичнее чем аналог на любой распостранёной скриптоте общего назначения. Отсюда — не ясен профит создания и поддержки нового языка (если только это не vendor lock).
Я уже молчу про то, что если бы это был например js, то встроить поддержку CMake в ваше любимое IDE заняло бы пару дней у плохо обученного школьника (и без костылей типа парсинга cbp файла).
Сильно сомневаюсь что можно найти, хоть какой то код на CMake, который будет выглядеть проще и лаконичнее чем аналог на любой распостранёной скриптоте общего назначения. Отсюда — не ясен профит создания и поддержки нового языка (если только это не vendor lock).
Я уже молчу про то, что если бы это был например js, то встроить поддержку CMake в ваше любимое IDE заняло бы пару дней у плохо обученного школьника (и без костылей типа парсинга cbp файла).
> Однако, имеется определённый порог вхождения, отсутсвие или слабая выразительность многих привычных языковых средств.
Это «отсутсвие или слабая выразительность» для системы сборки — как мана небесная, поскольку на cmake всё-таки собирают проекты, а не часы рисуют. Для этого выразительности не только хватает — её столько, что многие вещи сильно упрощаются, а писать хитровыгнутые конструкции желание пропадает. Я достаточно насмотрелся на SCons'овские скрипты от питонистов, которые во всю используют «привычные языковые средства» — разбираться в этом невозможно. Как результат, порог вхождения как раз намного ниже, чем если бы использовался язык общего назначения.
> Сильно сомневаюсь что можно найти, хоть какой то код на CMake, который будет выглядеть проще и лаконичнее чем аналог на любой распостранёной скриптоте общего назначения.
Как-бы DSL всегда быть проще и лаконичнее языков общего назначения. Несколько примеров я привёл выше.
> то встроить поддержку CMake в ваше любимое IDE
Да, давайте выбирать язык для системы сборки на основании лёгкости встраивания его в моё любимое IDE. Да и про лёгкость я бы поспорил — если и понадобится глубокий разбор cmake, то пожалуй проще будет разобрать его синтаксис, чем js, где нужное определение цели возможно придётся вытаскивать через несколько замыканий.
Это «отсутсвие или слабая выразительность» для системы сборки — как мана небесная, поскольку на cmake всё-таки собирают проекты, а не часы рисуют. Для этого выразительности не только хватает — её столько, что многие вещи сильно упрощаются, а писать хитровыгнутые конструкции желание пропадает. Я достаточно насмотрелся на SCons'овские скрипты от питонистов, которые во всю используют «привычные языковые средства» — разбираться в этом невозможно. Как результат, порог вхождения как раз намного ниже, чем если бы использовался язык общего назначения.
> Сильно сомневаюсь что можно найти, хоть какой то код на CMake, который будет выглядеть проще и лаконичнее чем аналог на любой распостранёной скриптоте общего назначения.
Как-бы DSL всегда быть проще и лаконичнее языков общего назначения. Несколько примеров я привёл выше.
> то встроить поддержку CMake в ваше любимое IDE
Да, давайте выбирать язык для системы сборки на основании лёгкости встраивания его в моё любимое IDE. Да и про лёгкость я бы поспорил — если и понадобится глубокий разбор cmake, то пожалуй проще будет разобрать его синтаксис, чем js, где нужное определение цели возможно придётся вытаскивать через несколько замыканий.
Однако, никто, пока что, так и не встроил CMake в ide, без костылестроения :) Если только JetBrains (надо бы потыкать).
Вот тот же qbs, можно без проблем встроить куда душа попросит, и я не сказал бы что там какой то адский синтаксис, жалко вот он сам собирает (как и упомянутый вами SCons), то бишь относится слегка к другому классу инструментов.
> Это «отсутсвие или слабая выразительность» для системы сборки — как мана небесная, поскольку на cmake всё-таки собирают проекты, а не часы рисуют.
По мимо сборки, на средних и больших проектах встречается ещё ряд задач, как то покрытие кода разного уровня тестами, различные виды анализа кодовой базы (часто специфичные для проекта), кодогенерация и прочие плюшки. В таком случае одна фигня приходится делать find_package(Python REQUIRED) и забавляться с кастомными целями, либо обрастать платформозависимым шелом.
Вот тот же qbs, можно без проблем встроить куда душа попросит, и я не сказал бы что там какой то адский синтаксис, жалко вот он сам собирает (как и упомянутый вами SCons), то бишь относится слегка к другому классу инструментов.
> Это «отсутсвие или слабая выразительность» для системы сборки — как мана небесная, поскольку на cmake всё-таки собирают проекты, а не часы рисуют.
По мимо сборки, на средних и больших проектах встречается ещё ряд задач, как то покрытие кода разного уровня тестами, различные виды анализа кодовой базы (часто специфичные для проекта), кодогенерация и прочие плюшки. В таком случае одна фигня приходится делать find_package(Python REQUIRED) и забавляться с кастомными целями, либо обрастать платформозависимым шелом.
Кто это «мы» видели?
И причем тут языки программирования?
Новый язык нафик не нужен, потому что есть C++, Java, их и так 100500. что мешает хотя бы C использовать вместо непонятного и ущербного cmake 2.8? Нахрена изучать новую матчасть, нахрена заставлять людей мучиться и себя тоже?
Лень арифметику указателей имплементировать?
Возьми стандарт ECMA Script, например готовый QtScript из того же Qt, там уже все реализовано, вставь в свой CMake и нечего какие то непонятные языки-велосипеды изобретать.
Если я бы был инвестором — послал бы нахрен этих изобретателей cmake 2.8, но Cmake ведь бесплатный.
И причем тут языки программирования?
Новый язык нафик не нужен, потому что есть 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)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стрелочные часы на CMake