Здравствуйте, vdimas, Вы писали:

V>Походу, разработчики CMake не в курсе как писать синтаксические анализаторы, поэтому синтаксис в языке CMake отсутствует.
V>В языке допустима лишь конструкция одного вида: fn([args ...]).

V>Поэтому даже if() else() endif() выглядят так как выглядят.

V>Т.е. это что-то вроде лиспа, где первая скобка стоит не там, поэтому всегда требуются даже пустые скобки, бгг.

Функции и скобки это как раз, IMHO, минимальная проблема. Основное, что я вижу, это
1) хохмы с тем, что они пытаются эмулировать логику шелла (Unquoted argument content consists of all text in a contiguous block of allowed or escaped characters. Both Escape Sequences and Variable References are evaluated. The resulting value is divided in the same way Lists divide into elements.) — но не хотят повторить её полностью.
2) Дальше, что переразбитие на аргументы делается и по пробелам, и по ';'. Или вот такое: (For example, the unquoted arguments -Da="b c", -Da=$(v), and a" "b"c"d are each interpreted literally. They may instead be written as quoted arguments "-Da=\"b c\"", "-Da=$(v)", and "a\" \"b\"c\"d", respectively.) — последний пример сбивает с толку — нет удобной возможности склеить выражения, когда её ожидаешь как раз тут естественным образом.
3) Потом смотришь на определения вида

find_program (
          <VAR>
          name | NAMES name1 [name2 ...] [NAMES_PER_DIR]
          [HINTS [path | ENV var]... ]
          [PATHS [path | ENV var]... ]

и первый вопрос — а может ли HINTS попасть в список NAMES? Если да, как его отличить от слова HINTS потом? если нет — почему этому мешают, и что делать, если оно там нужно?
Могу ли я этот список параметров для find_program сформировать где-то ещё и передать его туда одним готовым списком, типа find_program(${ARGS}), или оно будет разбирать этот список по словам до подстановки?
(Меня даже не интересует, как оно на самом деле работает. Меня интересует, чтобы чёткий метод был описан, чтобы можно было ему соответствовать. Сейчас такие вопросы их явно не волнуют совсем.)

Вопросы, вопросы... Я знаю, как это было бы написано правильно на любом из лиспов, просто сформировать структуру параметров и передать/вызвать. Я знаю, как написать корректную передачу всего и вся на TCL. На Python. Да на любом синтаксисе какого-то языка программирования, где все эти вопросы хоть как-то решены просто потому, что на нём пишут много и разнообразно.

Но тут они претендуют на то, что это язык программирования — в нём макры, скрипты поиска библиотек, плагины разные и т.п. — и тут же нарушают самые основы, превращая в самопротиворечивый язык описания.

N>>В любом случае, этот кошмар стал фактическим стандартом надолго и с этим фактом сложно что-то сделать.

V>Я надеюсь, что синтаксис у этого языка, таки, появится.

Со сломом легаси? Да я не против. Типа, вот вам версия 5.0, перепишите всё.
Какая часть народа на это пойдёт?
(ну да, можно не мытьём, так катаньем — новые фичи допускать только в новый синтаксис, и в каждом файле требовать заголовочную плашку с версией синтаксиса. Сработает. Но ругни будет до чёрта.)

Я по поводу их уже выводил (не тут) как общее правило — не умеете хорошо разрабатывать синтаксис — берите S-expressions, ближайший приемлемый интерпретатор лиспа/схемы, иначе купите себе селёдку и морочьте голову ей, а не нам.
Впрочем, и питон пойдёт не хуже, по нынешним временам. Жаль, что выиграл CMake, а не SCons, например.

V>Да, CMake умеет только работать над строками и их списками, что делает этот язык чемпионом по безопасности, но к вопросу наличия синтаксиса это немного перпендикулярно.

Ну вот хохмы типа "могу ли я передать слово HINTS в списке", как выше — это уже вопрос и безопасности (в обоих смыслах).

_>>>Это конечно возможно, т.к. индустрия далеко не всегда выбирает технически лучшие решения. Но это будет крайне печально для сообщества C++ и я надеюсь (хотя лично мне уже это не принципиально) что такого не случится.
N>>Ну если от всех платформ останется полдесятка (грубо говоря, RHEL+потомки/x86, Debian+потомки/x86, Windows/x86 и Android/AArch64) — то у такого были бы шансы.
N>>Но сейчас я вижу, что нет, фиг там. Вон новые ISA вроде RISC-V приходят, ARM отъедает серверный рынок, и прочая.

V>Да.
V>Поэтому, выиграет та технология, которая предложит больше для всех ниш и даром, такая технология автоматически окажется для индустрии важной.
V>И это будет не Conan на JFrog, бо слишком консервативные/закрытые, их потерю индустрия даже не заметит. ))

V>Выиграет что-то распис@яйское, типа vcpkg.
V>Т.е. что-то, куда можно влезть с ногами, полностью игнорируя исходных авторов проекта, написать вокруг и около что угодно своё в виде плагинов/дополнений/утилит и чтобы оно заработало, т.е. решало поставленные задачи.

Ну тогда это точно будет что-то Python или JS-based
Производительность собственной логике такой системы обычно неважна (кому важна, тот свою применит, таких <1/1000), а возможность на ходу подменить класс объекта, например, очень ценна.

V>Помнишь, Google составил критерии и согласно им перечислил проекты, который являются критически-важными для IT?
V>VCPKG там присутствует, Conan нет.
V>https://www.opennet.ru/opennews/art.shtml?num=54242

Ну их статистика весьма своеобразна — при анализе зависимостей что-то не видно учёта ценности самой зависимости, например.
Но какие-то начальные данные оно вполне может дать, угу.