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

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

Можно подумать, для дотнетных проектов это не так. ))

Изначально MSBuild знать не знает ни о C#, ни о C++.
Всё прописано в подключаемых props.
В дотнетных проектах что-то типа такого:

<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')"/>

В плюсовых такое:

<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />

С версии MSBuild 15.0 добавили новый SDK-тип проекта:

<Project Sdk="Microsoft.NET.Sdk">

Что является всего-лишь сокращённой формой записи ровно того же самого:

During evaluation of the project, MSBuild adds implicit imports at the top and bottom of the project file:

<Project>
    <!-- Implicit top import -->
    <Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk" />

    <PropertyGroup>
        <TargetFramework>net46</TargetFramework>
    </PropertyGroup>

    <!-- Implicit bottom import -->
    <Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk" />
</Project>

Т.е., немного синтаксического сахара конкретно для дотнета.

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

EP>>Нравиться тебе это или нет, но CMake таки используется в реальных проектах для описания C# под-проектов.
НС>В реальных проектах и Cobol с PHP используют. Это ж не повод считать это практику нормальной.

Да уж...

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

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

V>По ссылке:
V>

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

V>14-й не справляется для последних .Net Core-проектов.

Ты видел какая там версия в теге? В текущем варианте его зачем то переписали руками, но к путям он уже не прибит.

НС>>Если брать примерчик выше, то можно, к примеру, так же генерировать https://github.com/rsdn/CodeJam/blob/master/Build/Props/CodeJam.Targeting.props с синтаксисом ничуть не хуже cmake.
V>Сравнить с тем, что в варианте CMake будет что-то вроде создания в цикле объектов ProjectInfo из Compile.tt.

Ну я и говорю, функционально-логический vs императивный.

V>Плюс не будет расползания "знаний" по проекту.

Непонятно про какое такое расползание речь.

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

В msbuild можно сделать все ровно то же.

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

V>>Сравнить с тем, что в варианте CMake будет что-то вроде создания в цикле объектов ProjectInfo из Compile.tt.
НС>Ну я и говорю, функционально-логический vs императивный.

В Compile.tt по твоим ссылкам тоже императивный код.

Примерно то же самое происходит в CMake, только в рамках одного языка.
Проекты и их св-ва (в т.ч. различного рода зависимости) описываются декларативно.

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

Или можно повторять такое описание в цикле, порождая, например, сетку проектов с отличающимися параметрами, где эти отличающиеся параметры заданы в виде списка в аргументах.

Помимо объема кодирования в случае Compile.tt еще необходимо соблюдать спецификации, требуемые для корректного ручного генерирования MSBuild-файлов.
CMake генерит файлы MSBuild сам.


V>>Плюс не будет расползания "знаний" по проекту.
НС>Непонятно про какое такое расползание речь.

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


V>>CMake в этом смысле подкупает тем, что всевозможные флаги конфигураций, константы, пути и т.д. вводятся/обслуживаются, грубо, в одном месте.
НС>В msbuild можно сделать все ровно то же.

В MSBuild можно почти всё, т.к. он расширяем.
Вопрос не стоял может что-то MSBuild или нет.
Речь шла о цене — содержимое MSBuild-файлов более уместно для генерирования машиной, а не человеком.
Читабельность примерно нулевая.