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

EP>>CMake не восстанавливает проектный файл. Определение проекта записывается на языке CMake — это первоисточник.
S>Это потому, что для С++ никакого первоисточника нет. Есть горка файлов и сакральные знания о том, как эту горку файлов превратить во что-нибудь полезное.

Ещё раз, проект на CMake определяется вручную. Программист конкретного проекта пишет этот первоисточник на языке CMake.

S>Почему-то порождать, скажем, .cs файлы из CMake в голову не приходит — ну как же, cs файлы у нас пишет разработчик, ему за это деньги платят.

Генерация кода, хоть .cs, хоть .cpp, а потом сборка нагенерированного это одно из применений CMake, непонятно что тут удивительного — уверен это и в MS'овских xml'ках поддерживается

S>csproj — это такая же часть исходников проекта, как и .cs. Всё. Негде развернуться, применяя преимущества CMake. Дотнет прост, как угол дома.

Как уже многократно упомянули выше — обычно это применяется в тех случаях, где уже есть проект на C++, например библиотека, и нужно добавить примеры на разных языках, в том числе на C#. И вот очень удобно, когда проекты для C++ и для этих сторонних языков описываются в одной системе — можно переиспользовать общие части, например проектную обвязку для интеграционных тестов, для упаковки всего в инсталятор через CPack, также легко всё вместе тестировать, отправлять результаты в CDash и т.п.

S>А вот порождать при помощи CMake файл проекта — занахрена? С учётом того, что он при каждой сборке один и тот же...

1. Он не будет порождаться при каждой сборке — нет изменений, нет перегенирации.
2. Есть разные сценарии, в том числе когда порождаются разные проекты и солюшены. Я уже выше приводил пример — для внешнего использования один вариант, а для внутреннего, когда всё в одном месте собирается — другой.
3. CMake сам по себе удобнее студийных проектов — даже когда я писал код на C++ исключительно в одной версии MSVS — мне удобней было описывать проект на CMake, а не кликать в MSVS, и весь этот студийный xml'евский шлак находился в папке build, которая непринуждённо удалялась, а в репозитории лежал лаконичный CMakeLists.txt

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

EP>>Непонятно почему ты так рьяно разделяешь проекты на C++ и C#. То есть два проекта на C# в солюшн это норм, а C++ и C# — уже ай-ай-ай? В чём разница? В том что ты такого никогда не видел?
K>Обычно одни люди пишут на С++, а другие на шарпе,

А третьи на Python, четвёртые на Bash, пятые умеют складывать, шестые умножать.

K>в чём профит от того, что они будут работать в одном солюшене?

В чём недостаток для начала?
Типичный use-case такого гибрида — C++ библиотека с примерами использования на разных языках.

K>Я и проекты на шарпе предпочитаю разделять.
K>Ну, допустим, есть какая-то своя библиотека для реализации MVVM, если проект, который её использует.
K>Я разнесу это по разным репозиториям и солюшенам, т.к. завтра у меня может появиться ещё один проект, которому будет нужен MVVM и идеологически это всё не должно быть в куче.
K>...
K>Так а профит в чём с того, что они в одном солюшене?
K>Меня вот раздражает, что сейчас в одном репозитории и в одном солюшене основная прога и её Launcher, хотя оба на C#, даже пару общих библиотек используют. Пользы от этого так и не нашёл пока. Если бы раздельно были, мне лично было бы удобнее.

Что именно раздражает? Разделение действительно бывает необходимо по разным причинам. Но вот разделять ради разделения — это странно, ибо каждое разделение оно не бесплатное.

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

EP>Как уже многократно упомянули выше — обычно это применяется в тех случаях, где уже есть проект на C++, например библиотека, и нужно добавить примеры на разных языках, в том числе на C#. И вот очень удобно, когда проекты для C++ и для этих сторонних языков описываются в одной системе — можно переиспользовать общие части, например проектную обвязку для интеграционных тестов, для упаковки всего в инсталятор через CPack, также легко всё вместе тестировать, отправлять результаты в CDash и т.п.
Я по-прежнему не понимаю сценарий. Какое место в этом всём должно занимать порождение .csproj из CMake? Всё, что вы описываете, прекрасно делается просто при помощи вызова dotnet build из CMake и дальнейшей обработки результатов. Какие именно общие части вы собираетесь переиспользовать внутри сборки .net проекта?

EP>1. Он не будет порождаться при каждой сборке — нет изменений, нет перегенирации.
Изменений чего?
EP>2. Есть разные сценарии, в том числе когда порождаются разные проекты и солюшены. Я уже выше приводил пример — для внешнего использования один вариант, а для внутреннего, когда всё в одном месте собирается — другой.
Дайте ссылку — не вижу подробного описания сценария. По вашему краткому описанию напрашивается два таргета внутри солюшна (типа "internal" и "external"), или вообще два разных солюшна для двух разных наборов проектов, построенных поверх одних и тех же исходников.

EP>3. CMake сам по себе удобнее студийных проектов — даже когда я писал код на C++ исключительно в одной версии MSVS — мне удобней было описывать проект на CMake, а не кликать в MSVS, и весь этот студийный xml'евский шлак находился в папке build, которая непринуждённо удалялась, а в репозитории лежал лаконичный CMakeLists.txt
Повторюсь: сборка С++ — это лютый трэш и угар. Там, действительно, CMake может зарулить msbuild. Даже при одноплатформенной сборке.
В основном, насколько я понимаю, это потому, что нормальной документации по формату msbuild не существует. Я в прошлом году пытался сделать несложную, в общем-то, вещь — добавить в дотнет проект нативный код, который на винде должен порождать dll, а в линуксе — so. Я даже нашёл проект, сделанный энтузиастами, который заставляет msbuild использовать gcc вместо vc — чтобы можно было один и тот же проект собирать на обеих платформах.
Нашёл пару статей на хабре про то, как добавить в студийные проекты для С++ немного здравого смысла. Тем не менее, скажем, научить эту штуку корректно собирать ассемблерные фрагменты мне так и не удалось. Понять, что именно делается при помощи всех этих простыней .targets и .props, мне так и не удалось.
В противном случае, скорее всего можно было бы весь студийный xml-шлак заменить эквивалентным лаконичным xml. Который бы делал то же самое — минус, быть может, редактируемость в диалогах настроек MSVS.

Но всё это не имеет никакого отношения к дотнету. Он просто более нормально спроектирован с самого начала; его тулчейн нет нужды заменять на что-то более крутое.

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

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

EP>>>Непонятно почему ты так рьяно разделяешь проекты на C++ и C#. То есть два проекта на C# в солюшн это норм, а C++ и C# — уже ай-ай-ай? В чём разница? В том что ты такого никогда не видел?
K>>Обычно одни люди пишут на С++, а другие на шарпе,

EP>А третьи на Python, четвёртые на Bash, пятые умеют складывать, шестые умножать.

Ну, если там C# уровня Hello World, то вопросов нет.

K>>в чём профит от того, что они будут работать в одном солюшене?

EP>В чём недостаток для начала?

Ну, не знаю... Можно всё аккуратно по полочкам разложить, а можно устроить творческий беспорядок.
Как по мне, так для беспорядка должно быть обоснование

EP>Типичный use-case такого гибрида — C++ библиотека с примерами использования на разных языках.

Ну, вот у нас 10 разных языков. Плюсовик в основной библиотеке в новой версии добавил аргумент в функцию. Он же должен во всех 10 языках это изменение вносить?
Или потом начнётся зоопарк, что половина библиотек поддерживает новую версию, половина ещё только старую умеет, 100500 веток и соглашений по работе в репозитории?
А если будет отказ от дальнейшего развития библиотеки на руби каком-нибудь, то нужно будет её как-то выкидывать оттуда, чтобы не мешался и не отсвечивал? А если через год будет решено вернуть её?

K>>Я и проекты на шарпе предпочитаю разделять.
K>>Ну, допустим, есть какая-то своя библиотека для реализации MVVM, если проект, который её использует.
K>>Я разнесу это по разным репозиториям и солюшенам, т.к. завтра у меня может появиться ещё один проект, которому будет нужен MVVM и идеологически это всё не должно быть в куче.
K>>...
K>>Так а профит в чём с того, что они в одном солюшене?
K>>Меня вот раздражает, что сейчас в одном репозитории и в одном солюшене основная прога и её Launcher, хотя оба на C#, даже пару общих библиотек используют. Пользы от этого так и не нашёл пока. Если бы раздельно были, мне лично было бы удобнее.

EP>Что именно раздражает? Разделение действительно бывает необходимо по разным причинам. Но вот разделять ради разделения — это странно, ибо каждое разделение оно не бесплатное.

Ну, есть Launcher, у которого новая версия давно протестирована и работает, там изменился адрес сервера и теперь он должен отправлять в запускаемую основную программу другой URL.
Приходит срочный баг в старую версию программы, которая ещё используется, но уже с новой версией Launcher'а и нужно именно её починить. В итоге всё равно Launcher нужно брать из одной ветки и одного коммита, программу собирать из другого коммита и начинается вся эта беготня туда-сюда, т.к. рядом со старой программой лежит старый Launcher, который работает со старым URL и работать уже в новом окружении оно не будет.
Можно наверно как-то в git это намудрить с модулями или ещё чем или всякими CMake что-то нагенерировать, но мне лично проще и понятнее это вынести отдельно и хоть PowerShell скриптом в 5 строк в одну кучу собрать.
А у Launcher в git будут свои релизы, у программы свои, не нужно выдумывать какие-то тэги, что тут такая версия Lacunher, тут такая версия клиента, у каждого свой master и всё достаточно просто и понятно без лишних телодвижений.

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

EP>Давай сравним лаконичность.

От "ага, уже предвосхищаю недоумение" до "давай сравним лаконичность" — уже прогресс.
Ну а по делу — сравнивать императивный код и функционально-декларативный — ну то такое. Да и в целом разговоры за синтаксический оверхед пахнут.

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

S>По-прежнему не понимаю цель всех этих унизительных приседаний.

Да нет, местами такая фича весьма полезна — сквозные вещи на взрослых проектах вполне себе обычное явление. Вот, к примеру.
Вот только Evgeny.Panasyuk преподносит это нам как некое откровение, типа мы даже не подозреваем о таком. Хотя на самом деле msbuild вполне себе предоставляет примерно аналогичный функционал, хотя и весьма необычным для любителей cmake способом.

S> Почему-то порождать, скажем, .cs файлы из CMake в голову не приходит

Потому что есть Т4. Который, кстати, может использоваться для порождения не только cs, но и файлы сборки. Если брать примерчик выше, то можно, к примеру, так же генерировать https://github.com/rsdn/CodeJam/blob/master/Build/Props/CodeJam.Targeting.props с синтаксисом ничуть не хуже cmake.

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

EP>Ещё раз, проект на CMake определяется вручную. Программист конкретного проекта пишет этот первоисточник на языке CMake.

Ты не поверишь, но в современных реалиях csproj тоже отчасти пишется вручную. Там уже совсем необязательно поименно поминать все исходники, явно упоминаются только те файлы, для которых свойства установлены отличными от дефолтных. И точно так же есть масса возможностей по устранению копипасты, от фич самого языка msbuild (с поправкой на его функционально логическую, а не императивную природу) до возможности написания собственных тасок на любом удобном языке.

EP>Генерация кода, хоть .cs, хоть .cpp, а потом сборка нагенерированного это одно из применений CMake, непонятно что тут удивительного — уверен это и в MS'овских xml'ках поддерживается

Для генерации кода есть совсем другой инструмент, Т4. Ну и в совсем свежих версиях еще и интегрированные в компилятор source generators.

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

N>А он может скачать свежие исходники какой-нибудь библиотеки с условного Гитхаба и собрать проект с ней? А в случае неудачи, использовать то, что есть локально? Он может парсить и редактировать файлы исходников? кросс компиляция для другой ОС?
Да, всё это доступно в msbuild. Там трижды-тьюринг полная систма сборки. Там есть магическая команда Exec, с помощью которой ты можешь вызвать git clone, свой генератор или ещё что-нибудь другое влючая кастомные таски с более плотной интеграцией. Более того, если на следующем этапе инкрементальной сборки появится новая цель — она выполнится... Тут вопрос на практике как его не вызывать лишний раз, и в той же студии есть отдельный механизм "fast up-to-date check", который опять же рулится через msbuild.

Вообще, если серьезно — то просто, стоит открыть .NET SDK и посчитай кол-во строчек в .targets и .props файлов, и осознать наконец насколько бесполезно это пытаться повторить на коленочках сбоку. Именно поэтому не стоит это пытаться повторять. А если ты знаешь что ты хочешь конкретно сделать (позвать компилятор с параметрами?) — то вопроса бы не было бы в принципе. Весь совет в том, что не стоит игнорировать платформенные тулзы — платформа в данном случае — dotnet.

И если уж совсем к финалу, то я поклонник GN + ninja, GN => отлично генерирует и .sln/.proj файлы, но это лишь сопроводительная часть сборки. А настоящая часть сборки это ninja. Как ни странно — многие системы сборки не понимают как правильно работать с timestamps, включая msbuild, увы.

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

MA>> Выполняет MSBuild. Для людей знакомых с темой должно быть понятно, что системы сборки настолько НЕ эквивалентны, что не стоит пытаться решить несуществующую задачу.
EP>CMake это build system generator.
Который можно выкинуть в мусорку. Евгений — вы на высоте. Не надо со своим болотом грести в вещи в которых не понимаете.

Здравствуйте, Ночной Смотрящий, Вы писали:

S>>По-прежнему не понимаю цель всех этих унизительных приседаний.
НС>Да нет, местами такая фича весьма полезна — сквозные вещи на взрослых проектах вполне себе обычное явление. Вот, к примеру.
НС>Вот только Evgeny.Panasyuk преподносит это нам как некое откровение, типа мы даже не подозреваем о таком.

Ага, прикольно, а предыдущем предложении ты объясняешь коллеге который таки не подозревает.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ну а по делу — сравнивать императивный код и функционально-декларативный — ну то такое.

Если решается одна и та же задача — то вполне себе.
Или в чём поинт? Типа ничего что там трёхэтажный монстр, зато функционально-декларативно?

НС>Да и в целом разговоры за синтаксический оверхед пахнут.

Ничем не подкреплённое блаб-высказывание. А аналог на .xml ты так и не привёл.

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

MA>>> Выполняет MSBuild. Для людей знакомых с темой должно быть понятно, что системы сборки настолько НЕ эквивалентны, что не стоит пытаться решить несуществующую задачу.
EP>>CMake это build system generator.
MA> Который можно выкинуть в мусорку. Евгений — вы на высоте. Не надо со своим болотом грести в вещи в которых не понимаете.

Нравиться тебе это или нет, но CMake таки используется в реальных проектах для описания C# под-проектов. Мир он намного богаче твоих вымышленных наивных рамок

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

EP>>1. Он не будет порождаться при каждой сборке — нет изменений, нет перегенирации.
S>Изменений чего?

Изменений описания проекта на языке CMake.

EP>>2. Есть разные сценарии, в том числе когда порождаются разные проекты и солюшены. Я уже выше приводил пример — для внешнего использования один вариант, а для внутреннего, когда всё в одном месте собирается — другой.
S>Дайте ссылку — не вижу подробного описания сценария. По вашему краткому описанию напрашивается два таргета внутри солюшна (типа "internal" и "external"), или вообще два разных солюшна для двух разных наборов проектов, построенных поверх одних и тех же исходников.

Вот кто будет эти два разных солюшена описывать, и например добавлять новые под-проекты, вносить измения? Вручную от забора и до обеда?

EP>>3. CMake сам по себе удобнее студийных проектов — даже когда я писал код на C++ исключительно в одной версии MSVS — мне удобней было описывать проект на CMake, а не кликать в MSVS, и весь этот студийный xml'евский шлак находился в папке build, которая непринуждённо удалялась, а в репозитории лежал лаконичный CMakeLists.txt
S>... Тем не менее, скажем, научить эту штуку корректно собирать ассемблерные фрагменты мне так и не удалось. Понять, что именно делается при помощи всех этих простыней .targets и .props, мне так и не удалось.

О том и речь, а теперь представь что вместо этих простыней обычный процедурный код, который получается достаточно лаконичным, и если даже где есть boilerplate — то его можно один раз спрятать в процедуру и не засорять каждый раз место использования.
И эти фичи они не специфичны для C++ — например самые разнообразные интеграционные тесты и кодогенерация — какая-то одна фича предоставленная системой сборки не покроет всего разнообразия потребностей, и вот тут возможность расширения своими процедурами (пусть даже примитивными) — играет большую роль.

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

K>>>в чём профит от того, что они будут работать в одном солюшене?
EP>>В чём недостаток для начала?
K>Ну, не знаю... Можно всё аккуратно по полочкам разложить, а можно устроить творческий беспорядок.
K>Как по мне, так для беспорядка должно быть обоснование

Ну можно аккуратно по полочкам разложить в рамках одного солюшена

EP>>Типичный use-case такого гибрида — C++ библиотека с примерами использования на разных языках.

K>Ну, вот у нас 10 разных языков. Плюсовик в основной библиотеке в новой версии добавил аргумент в функцию. Он же должен во всех 10 языках это изменение вносить?

Ну да, либо состыковаться со специально-обученными людьми которые умеют добавить аргумент на языке X.
Другой вариант — автогенерация. К примеру SWIG — он именно под это и заточен — генерировать интерфейсы к C++ для десятка языков.

K>Или потом начнётся зоопарк, что половина библиотек поддерживает новую версию, половина ещё только старую умеет, 100500 веток и соглашений по работе в репозитории?

А вот не надо разводить зоопарк. Прогон сборки и тестов всего солюшена ткнёт носом во всем примеры что сломались — дальше дело техники.

K>А если будет отказ от дальнейшего развития библиотеки на руби каком-нибудь, то нужно будет её как-то выкидывать оттуда, чтобы не мешался и не отсвечивал? А если через год будет решено вернуть её?

"Выкинуть" можно одним флажком, CMake описание это же код.

K>В итоге всё равно Launcher нужно брать из одной ветки и одного коммита, программу собирать из другого коммита и начинается вся эта беготня туда-сюда, т.к. рядом со старой программой лежит старый Launcher, который работает со старым URL и работать уже в новом окружении оно не будет.
K>Можно наверно как-то в git это намудрить с модулями

Это обычные git submodules — каждая ветка программы может указывать может указывать на один и тот же коммит лаунчера из под-модуля — если это именно то что хочется.

K>но мне лично проще и понятнее это вынести отдельно и хоть PowerShell скриптом в 5 строк в одну кучу собрать.

Ага, а потом ещё и внешний скрипт для интеграционных тестов лаунчера и программы.

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

S>>... Тем не менее, скажем, научить эту штуку корректно собирать ассемблерные фрагменты мне так и не удалось. Понять, что именно делается при помощи всех этих простыней .targets и .props, мне так и не удалось.

EP>О том и речь, а теперь представь что вместо этих простыней обычный процедурный код, который получается достаточно лаконичным, и если даже где есть boilerplate — то его можно один раз спрятать в процедуру и не засорять каждый раз место использования.
Так там проблема не в простынях, а в том, чтобы понять, что они делают. CMake же не святым духом работает — он порождает ровно те же .targets и .props, чтобы потом можно было вызвать msbuild.
EP>И эти фичи они не специфичны для C++ — например самые разнообразные интеграционные тесты и кодогенерация — какая-то одна фича предоставленная системой сборки не покроет всего разнообразия потребностей, и вот тут возможность расширения своими процедурами (пусть даже примитивными) — играет большую роль.
Тут неподалёку есть коллега vdimas — так вот он собаку съел на порождении msbuild проектов из CMake.
Наверняка он сможет вам помочь.

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

EP>Если решается одна и та же задача — то вполне себе.

Нюанс в том, что задача далеко не одна, и сравнивать надо как минимум набор часто встречающихся. А специально выьбирать задачу, удобную для одного подхода и неудобную для другого (в данном случае ты прям в императивных терминах ее и сформулировал) — это, уж извини, демагогия.

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

EP>Ага, прикольно, а предыдущем предложении ты объясняешь коллеге который таки не подозревает.

Ты это как опеределил? И, помнится, ты там обобщающий квантор использовал, а вовсе не конкретного коллегу упомянул.

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

EP>Нравиться тебе это или нет, но CMake таки используется в реальных проектах для описания C# под-проектов.

В реальных проектах и Cobol с PHP используют. Это ж не повод считать это практику нормальной.

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

S>>>Не очень понимаю, вам это всё зачем? Вы хотите порождать проект автоматически?
BB>>Да, погуглите CМake для общего развития. Он уже много лет в MSVC есть
S>Повторю вопрос: вам это всё зачем?

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


S>Обычно проект создаётся один раз.

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


S>А потом много лет развивается. Поэтому не очень важно, как именно устроено порождение проекта.

Но ветвиться по флагам в XML MSBuld — то еще удовольствие.
И студия порой глючит, если этот XML слишком сложный, со множеством условных включений, где параметры подаются для MSBuild во время билда, но у "просто файла проекта" этих флагов нет.

Чтобы Студия нормально понимала такой проект, в нём надо описывать бесконечные сетки конфигураций с предопределёнными комбинациями флагов.

И непонятно что делать с sln-файлами, т.к. у них ср-ва конфигурирования совсем бедные — т.е. как в зависимости от выбранной конфигурации включать-отключать проекты из билда?
Это надо содержать сетку sln-файлов подо всю комбинаторику флагов?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Потому что есть Т4. Который, кстати, может использоваться для порождения не только cs, но и файлы сборки.

По ссылке:

const string msBuildExe = @"%ProgramFiles(x86)%\MSBuild\14.0\Bin\MSBuild.exe";

14-й не справляется для последних .Net Core-проектов.
И может быть установлен не туда, куда указывает константа.

Сейчас вообще привязали версию MSBuild к Студии, поэтому, искать надо через Студию.

MSBuild is installed in the \Current folder under each version of Visual Studio, and the executables are in the \Bin subfolder.

На CMake:

cmake_host_system_information(RESULT vsdir QUERY "VS_16_DIR")
set(msbuild "${vsdir}/MSBuild/Current/Bin/MsBuild.exe")
message(STATUS "MSBBuild path: ${msbuild}")

У меня выдаёт:

-- MSBBuild path: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/Bin/MsBuild.exe

НС>Если брать примерчик выше, то можно, к примеру, так же генерировать https://github.com/rsdn/CodeJam/blob/master/Build/Props/CodeJam.Targeting.props с синтаксисом ничуть не хуже cmake.

Сравнить с тем, что в варианте CMake будет что-то вроде создания в цикле объектов ProjectInfo из Compile.tt.
На этом всё.
Остальное делается "само".

Плюс не будет расползания "знаний" по проекту.
CMake в этом смысле подкупает тем, что всевозможные флаги конфигураций, константы, пути и т.д. вводятся/обслуживаются, грубо, в одном месте.

Шаблонизаторы можно тоже всякие запускать, но для простых вещей уместен встроенный подстановщик переменных:

[assembly: AssemblyTitle("@PROJECT_NAME@")]
[assembly: AssemblyVersion("@PROJECT_VERSION_MAJOR@.@PROJECT_VERSION_MINOR@.@PROJECT_VERSION_PATCH@.0")]
[assembly: AssemblyFileVersion("@PROJECT_VERSION_MAJOR@.@PROJECT_VERSION_MINOR@.@PROJECT_VERSION_PATCH@.0")]

Ну и, хотя язык CMake я презираю за его убожество, но сравнивать с XML его всё-равно бесполезно. ))