Re: Можно ли создать .net 5.0 проект в CMake? - .NET

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

S>>>>Не очень понимаю, вам это всё зачем? Вы хотите порождать проект автоматически?
N>Раз уж речь, про cmake, то он как раз и используется для генерации проектов, включения и исключения их массово.
N>Например, есть большой проект OoenCV. В максимальной комплектации он вполне может включать в себя тысячу проектов. Отключать можно что угодно: тесты, примеры, проекты для интеграции с Питоном, Java, Julia... Можно отдельные модули.

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

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

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

S>>В C# не бывает такого, что на винде применяем .csproj, а на линуксе — какие-нибудь мейк-файлы.

EP>Ну и здорово. Даже если бэкэнд всегда один, и софт совсем не кроссплатформенный — CMake он сам по себе удобен. Удобнее студийных xml'ек, удобнее голого Make'а.
Если бы он был удобнее, то вопроса, как породить csproj, не возникало бы. И дотнет вполне себе кроссплатформенный — в отличие от того же С++. Как раз потому, что в нём зоопарка нет. В нём один и тот же csproj порождает один и тот же байткод что на винде, что на линуксе. И запустить можно и тот и другой виды кода на каждой из платформ. Не нужно иметь пятьдесят билд таргетов под каждую экзотическую архитектуру. Просто dotnet build — и всё.
EP>Проектный файл выраженный на языке CMake получается достаточно лаконичным. За счёт того что можно определять функции — можно легко убирать boilerplate из проектного файла и делать рефакторинг по мере роста проекта (ага, уже предвосхищаю недоумение — как так рефакторить проектный файл — а вот как обычный код).

По-прежнему не понимаю цель всех этих унизительных приседаний. Почему-то порождать, скажем, .cs файлы из CMake в голову не приходит — ну как же, cs файлы у нас пишет разработчик, ему за это деньги платят.
csproj — это такая же часть исходников проекта, как и .cs. Всё. Негде развернуться, применяя преимущества CMake. Дотнет прост, как угол дома.

Если хочется странного, то можно попытаться полностью перейти от msbuild к CMake. Но тогда вопрос про порождение файла проекта будет нерелевантен. Зачем нам файл проекта, если весь тулчейн будет вызываться напрямую из CMake?
Просто будем звать Nuget и csc для того, чтобы скачать зависимости и, собственно, скомпилировать сборки. Делов-то. Ну, там, надо будет, конечно, подтащить всё, что в msbuild уже утоптали — вроде вызова T4 и прочих генераторов — но в целом, наверное, можно даже получить более хороший результат. В частности, в проектах, которые сращивают С++ с C# — потому что в плюсах со сборкой по прежнему какой-то трэш и угар.

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

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

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

MA>> MSBuild гораздо мощнее любых недо-make. И в этом же его ахилесова пята, потому что туда интегрировано всё на свете, включая менеджер пакетов. (грубо говоря)

N>А он может скачать свежие исходники какой-нибудь библиотеки с условного Гитхаба и собрать проект с ней? А в случае неудачи, использовать то, что есть локально? Он может парсить и редактировать файлы исходников? кросс компиляция для другой ОС?

Если очень хочется, то можно вставить произвольный код, который сделает что угодно.
https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-inline-tasks?view=vs-2019

Кросскомпиляция C# существует уже давно.
В чём вопрос?

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

S>>>Не очень понимаю, вам это всё зачем? Вы хотите порождать проект автоматически?

Раз уж речь, про cmake, то он как раз и используется для генерации проектов, включения и исключения их массово.
Например, есть большой проект OoenCV. В максимальной комплектации он вполне может включать в себя тысячу проектов. Отключать можно что угодно: тесты, примеры, проекты для интеграции с Питоном, Java, Julia... Можно отдельные модули. Если нет зависимости для какого-то модуля, то автоматически отключаются все, которые зависят от него. Можно собирать все модули статически, можно каждый в своей dll, можно все в одной большой dll.
Можно для windows, Linux, mac, android, ios...Можно выбирать тулчейны для сборки. Он сам скачивает зависимости с гитхаба. Или данные (веса нейросетки), или библиотеки (Intel IPP). Собирает, копирует, делает install.

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

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

K>>Мне видится логичным отдельно собирать более классическими инструментами проект на С++ и отдельными инструментами на C#

EP>Ну вот для C++ CMake генерирует проект студии на Windows, а на Linux например Makefile.
EP>И соответственно раз и C++ и C# проекты будут в одном solution — между ними будут правильные зависимости.

Зачем их в один солюшен пихать?
Ну, так конечно быстрее пилить изменения и там и там одновременно.
Но не "правильнее" ли отдельно собирать dll на С++, прописывать для неё тесты и т.п., а в C# уже подсовывать протестированную библиотеку и не пересобирать её каждый раз?
А если у библиотеки есть обёртки на десятки языков, то все их в один солюшен пихать и каждому разработчику настраивать полностью окружение, хотя он кроме C# ничего и не знает и пилит только библиотеку на этом языке?

K>>а потом уже третьим инструментом для деплоя всё в кучу согребать.

EP>А зачем третий инструмент, если CMake справляется и с тестами (CTest/CDash) и с упаковкой (CPack)?

Ну, если оно всё хорошо работает и поддерживает, то смысла нет.
Пока я вижу странный вопрос и никто на него не ответил, значит никто не знает, корректно ли работает CMake с .NET 5

K>>Можно конечно всё в один репозиторий засунуть и собирать одним файликом, но как-то больше на кашу похоже, в которой потом сложно разобраться.

EP>Ну большие проекты обычно не описываются одним файликом, а вполне себе иерархией из файликов.
EP>На счёт отдельного репозитория — ну кончено можно, но зачем? При нормальной структуре директорий никакой каши нет. Если вопрос конечно в разделении прав доступа — то да, можно вынести в git submodule.

Ну, если в команде все всем занимаются, то можно не париться, а если я разработчик C#, то зачем мне в солюшене проекты на C++ и зачем я их у себя буду собирать, если не меняю ничего там?

K>>Ну, может конечно там проект на C# — это обёртки для вызова функций из С++библиотеки и C# генерируется на лету на основе кода С++ или ещё что-то подобное.

EP>Он может как генерироваться, так и быть написан в ручную. В чём разница в обсуждаемом контексте?

Если генерируется, значит для сборки C# нужен код на C++ и есть зависимость. Если же код на шарпе пишется, значит он живёт отдельно, нет никакой зависимости и можно спокойно проект собирать отдельно.

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

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

либо что-то хитрое можно было бы сделать на xml и проект собирался бы 5 минут, а в итоге будет что-то заинлайнено так, как решили разработчики CMake и вот уже сборка 15 минут.

K>>Про EF тоже говорят, что можно в SQL не лезть и само сгенерируется, а по факту лучше всё перепроверять, а то там нагенерируется, что волосы дыбом встают.

EP>Вот как-то не приходилось лезть во внутрь файлов студийных проектов сгенерированных CMake (VS2003 — VS2015) — оно просто работало, я даже не помню что там внутри. Результирующие опции компиляции посмотреть — да, но это больше для отладки своих настроек и проектных файлов, а не того как именно CMake нагенерировал.

Да большинство их в принципе наверно не открывало и понятия не имеют что там написано и что там xml. Знают, что вот можно выбрать в IDE Debug или Release сборку, нажал F5 и заработало.
Оно в принципе и не плохо наверно.

Я как бы не против CMake и вероятно кому-то оно действительно нужно и полезно. Вопрос насколько он популярен в рамках .NET, как оперативно в него новые штуки добавляют, насколько большое комьюнити, чтобы искать и фиксить баги,... Собственно я сугубо из-за этого за более популярные решения. Ни разу просто не слышал, чтобы CMake шарписты использовали, собственно из-за этой темы только узнал, что он оказывается в принципе поддерживает проекты под .NET.

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

BB>Знатоки правильно предположили, что проект кросс-платформенный и на 90% написан на C++, доля C# в нём невелика.
BB>.NET Framework тоже не сразу, kitware потребовалось много лет, но C# стал поддерживаться из коробки. На данный момент файлы .net core проектов генерируются CMake с использованием file(APPEND ...), но это совсем не то, за что мы его любим

Потому и спросил, вдруг я чего-то не знал...
Я по-прежнему не понимаю, для чего потребовалось именно порождать проект C#. Это на С++ нет понятия "проекта", и поэтому CMake и прочие инструменты вынуждены изгаляться, восстанавливая проектный файл на лету.
В C# не бывает такого, что на винде применяем .csproj, а на линуксе — какие-нибудь мейк-файлы.
Считайте, что .csproj — это исходник. Я уверен, что cmake способен вызвать dotnet build в нужном месте.
Этого вполне достаточно для того, чтобы в одних "конфигурациях" собирать дотнет, в других — не собирать. А ситуацию, что вам нужно из одних и тех же .cs исходников собирать то unsafe-библиотеку, то safe-екзешник, я почему-то себе представить не могу.

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

S>Я по-прежнему не понимаю, для чего потребовалось именно порождать проект C#.

Для начала нужно разобраться что же делает CMake.

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

CMake не восстанавливает проектный файл. Определение проекта записывается на языке CMake — это первоисточник.

S>В C# не бывает такого, что на винде применяем .csproj, а на линуксе — какие-нибудь мейк-файлы.

Ну и здорово. Даже если бэкэнд всегда один, и софт совсем не кроссплатформенный — CMake он сам по себе удобен. Удобнее студийных xml'ек, удобнее голого Make'а.
Проектный файл выраженный на языке CMake получается достаточно лаконичным. За счёт того что можно определять функции — можно легко убирать boilerplate из проектного файла и делать рефакторинг по мере роста проекта (ага, уже предвосхищаю недоумение — как так рефакторить проектный файл — а вот как обычный код).

Здравствуйте, 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

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

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

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

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

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

Да уж...

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

Вот просто как в .net Framework, но только с чем-нибудь вроде set(DOTNET_TARGET_FRAMEWORK "net5.0") в CMakeLists, а потом `cmake .` и готово? Безо всяких там сгенериривать один проект, а потом руками/powershell-скриптом его исправить, и прочих танцев с бубном?

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

BB>Вот просто как в .net Framework, но только с чем-нибудь вроде set(DOTNET_TARGET_FRAMEWORK "net5.0") в CMakeLists, а потом `cmake .` и готово? Безо всяких там сгенериривать один проект, а потом руками/powershell-скриптом его исправить, и прочих танцев с бубном?

dotnet build и dotnet publish он из коробки и 1) кроссплатформенный 2) кроссверсионный. ос и проц задается параметром -r а версия фрейморка -f. Если нужны native библотеки это dotnet тоже из коробки разруливает.

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

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

BB>>Вот просто как в .net Framework, но только с чем-нибудь вроде set(DOTNET_TARGET_FRAMEWORK "net5.0") в CMakeLists, а потом `cmake .` и готово? Безо всяких там сгенериривать один проект, а потом руками/powershell-скриптом его исправить, и прочих танцев с бубном?

_NN>Расскажете чем dotnet build не подходит ?

dotnet build собирает проект из готовых proj/sln, а CMake как раз эти самые proj/sln генерирует.
Вопрос как раз был, как их сгенерировать, а не что делать с ними потом

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

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

BB>>Вот просто как в .net Framework, но только с чем-нибудь вроде set(DOTNET_TARGET_FRAMEWORK "net5.0") в CMakeLists, а потом `cmake .` и готово? Безо всяких там сгенериривать один проект, а потом руками/powershell-скриптом его исправить, и прочих танцев с бубном?

VC>dotnet build и dotnet publish он из коробки и 1) кроссплатформенный 2) кроссверсионный. ос и проц задается параметром -r а версия фрейморка -f. Если нужны native библотеки это dotnet тоже из коробки разруливает.

вопрос был не про то, как имея proj/sln файлы что-нибудь собрать, как это делает dotnet build, а про то, как эти самые proj/sln сгенерировать

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

VC>>>dotnet build и dotnet publish он из коробки и 1) кроссплатформенный 2) кроссверсионный. ос и проц задается параметром -r а версия фрейморка -f. Если нужны native библотеки это dotnet тоже из коробки разруливает.

BB>>вопрос был не про то, как имея proj/sln файлы что-нибудь собрать, как это делает dotnet build,

VC>не. я не писал как собрать.

А что же тогда по-вашему на самом деле делает dotnet build?

BB>> а про то, как эти самые proj/sln сгенерировать

VC>😂😂😂

VC>dotnet new умеет генерировать proj

В CMake файлы в проект добавляют примерно так:
SET(TARGET_SRC
Main.cs
../Connection.cs
../../common/Logger.cs
)
А как это сделать в коммандой строке dotnet new? Как добавить нужные assembly или просто сделать код unsafe?

Здравствуйте, BigBoss, Вы писали:
VC>>dotnet new умеет генерировать proj

https://docs.microsoft.com/ru-ru/dotnet/core/tools/dotnet-add-package
или просто сделать код unsafe?
BB>https://docs.microsoft.com/ru-ru/dotnet/core/tools/
Для этого надо редактировать файл проекта.

Не очень понимаю, вам это всё зачем? Вы хотите порождать проект автоматически? А код для него возьмётся откуда?

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

S>Здравствуйте, BigBoss, Вы писали:
VC>>>dotnet new умеет генерировать proj

S>https://docs.microsoft.com/ru-ru/dotnet/core/tools/dotnet-add-package
S>или просто сделать код unsafe?
BB>>https://docs.microsoft.com/ru-ru/dotnet/core/tools/
S>Для этого надо редактировать файл проекта.

А откуда он берётся, этот "файл проекта"?

S>Не очень понимаю, вам это всё зачем? Вы хотите порождать проект автоматически?

Да, погуглите CМake для общего развития. Он уже много лет в MSVC есть

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

BB>>>вопрос был не про то, как имея proj/sln файлы что-нибудь собрать, как это делает dotnet build,

Выполняет MSBuild. Для людей знакомых с темой должно быть понятно, что системы сборки настолько НЕ эквивалентны, что не стоит пытаться решить несуществующую задачу.

MSBuild гораздо мощнее любых недо-make. И в этом же его ахилесова пята, потому что туда интегрировано всё на свете, включая менеджер пакетов. (грубо говоря)

Поэтому единственный правильный способ работы с C#/dotnet и организовать сборку там — это не игнорировать встроенные возможности. Собрать проекты с помощью csc — это не проблема. Проблемы начнуться когда начнут просвечивать нюансы, особенно через года, да такие о которых вы знать не слыхивали.

Просто откройте дотнет сдк и посчитайте размер *.targets и *.props файлов. После этого — если и были вопросы — желание повторить хотя бы четвертинку из этого — должна отпасть.

Здравствуйте, BigBoss, Вы писали:
BB>А откуда он берётся, этот "файл проекта"?

dotnet new

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

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

MA> MSBuild гораздо мощнее любых недо-make. И в этом же его ахилесова пята, потому что туда интегрировано всё на свете, включая менеджер пакетов. (грубо говоря)

А он может скачать свежие исходники какой-нибудь библиотеки с условного Гитхаба и собрать проект с ней? А в случае неудачи, использовать то, что есть локально? Он может парсить и редактировать файлы исходников? кросс компиляция для другой ОС?

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

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

_NN>В чём вопрос?

Вопрос в том, что глупо называть кроссплатформенный, тьюринг-полный cmake, с помощью которого собирается куча проектов, недомэйком. Он более мета инструмент, чем msbuild

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

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

В случае CMake это не так. Проект порождается сколько угодно раз, с какими угодно настройками из CMake-овского кода. И изменения вносятся непосредственно в CMake'овский код, что приводит к регенерации всего или части проектных файлов.
Грубо говоря CMake это не обычная система сборки. Он использует другие системы сборки как бэкэнды, и из единого описания проекта можно генерировать проектные файлы для разных бэкэндов.

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

BB>>>>вопрос был не про то, как имея proj/sln файлы что-нибудь собрать, как это делает dotnet build,
MA> Выполняет MSBuild. Для людей знакомых с темой должно быть понятно, что системы сборки настолько НЕ эквивалентны, что не стоит пытаться решить несуществующую задачу.

CMake это build system generator.

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

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

S>>>>>Не очень понимаю, вам это всё зачем? Вы хотите порождать проект автоматически?
N>>Раз уж речь, про cmake, то он как раз и используется для генерации проектов, включения и исключения их массово.
N>>Например, есть большой проект OoenCV. В максимальной комплектации он вполне может включать в себя тысячу проектов. Отключать можно что угодно: тесты, примеры, проекты для интеграции с Питоном, Java, Julia... Можно отдельные модули.

EP>Преимущество не только в гибкой конфигурации, но например ещё и в том что можно обобщать и переиспользовать отдельные куски как функции/макросы, делать циклы по каким-либо последовательностям и т.п.
EP>Например есть десяток целей определение которых отличается лишь одним параметром — соответственно это можно выразить как функцию с одним параметром и цикл по списку этих параметров вызывающий эту функцию. С развитием проекта можно рефракторить и обобщать, так как определение проекта это обычный код.

Есть подозрение, что если вместо CMake взять MSBuild и так же с ним заморочиться, то окажется, что всё это можно сделать и на xml, но это ж разбираться надо, а CMake кто-то когда-то уже изучил и зачем что-то новое учить

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

K>Есть подозрение, что если вместо CMake взять MSBuild и так же с ним заморочиться, то окажется, что всё это можно сделать и на xml, но это ж разбираться надо, а CMake кто-то когда-то уже изучил и зачем что-то новое учить

Писать код на xml? Ну, так себе

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

BB>Вот просто как в .net Framework, но только с чем-нибудь вроде set(DOTNET_TARGET_FRAMEWORK "net5.0") в CMakeLists, а потом `cmake .` и готово? Безо всяких там сгенериривать один проект, а потом руками/powershell-скриптом его исправить, и прочих танцев с бубном?

Неужели проще было создать тему, а не проверить эту строчку?
CMake в мире C# использует 5 человек наверно.
Учитывая, что на оф. сайте пишут, что поддерживают даже проекты от 2022 студии в экспериментальном режиме, учитывая принцип работы всего этого добра, нет никаких причин к тому, чтобы CMake работал с .NET FW и не работал с .NET 5

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

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

K>>Есть подозрение, что если вместо CMake взять MSBuild и так же с ним заморочиться, то окажется, что всё это можно сделать и на xml, но это ж разбираться надо, а CMake кто-то когда-то уже изучил и зачем что-то новое учить

N>Писать код на xml? Ну, так себе

Ну, я не осилил xml и себе взял Cake для настройки сборки, но я и проекты не генерирую, а просто вызываю MSBuild с нужными ключами сборки, выходной папкой и т.п.

А преимущества разные могут быть. Например этот .net проект лишь часть большого кросплатформенного проекта на C++, и вот когда сборка идёт на Windows — нужно заодно и сгенирировать несколько C# проектов в довесок — лично видел такие проекты, CMake здесь рулит неимоверно. Плюс весь набор проектных утилит который обычно уже есть на CMake можно применить и для C# проектов, а не разбираться какие там фичи MS соизволила завезти в .xml и с каким причудами

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

K>>Есть подозрение, что если вместо CMake взять MSBuild и так же с ним заморочиться, то окажется, что всё это можно сделать и на xml, но это ж разбираться надо, а CMake кто-то когда-то уже изучил и зачем что-то новое учить

N>Писать код на xml? Ну, так себе

Справедливости ради CMake-овский язык тоже очень далёк от идеала, но таки да, на порядки лучше .xml'я.
Нормальные функции/макросы, нормальные циклы с любой вложенностью и без тонны синтаксического мусора.

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

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

K>>Есть подозрение, что если вместо CMake взять MSBuild и так же с ним заморочиться, то окажется, что всё это можно сделать и на xml, но это ж разбираться надо, а CMake кто-то когда-то уже изучил и зачем что-то новое учить

EP>А преимущества разные могут быть. Например этот .net проект лишь часть большого кросплатформенного проекта на C++, и вот когда сборка идёт на Windows — нужно заодно и сгенирировать несколько C# проектов в довесок — лично видел такие проекты, CMake здесь рулит неимоверно. Плюс весь набор проектных утилит который обычно уже есть на CMake можно применить и для C# проектов, а не разбираться какие там фичи MS соизволила завезти в .xml и с каким причудами

Наверно у меня не было просто соответствующих проектов.

Мне видится логичным отдельно собирать более классическими инструментами проект на С++ и отдельными инструментами на C#, а потом уже третьим инструментом для деплоя всё в кучу согребать.
Можно конечно всё в один репозиторий засунуть и собирать одним файликом, но как-то больше на кашу похоже, в которой потом сложно разобраться.
Ну, может конечно там проект на C# — это обёртки для вызова функций из С++библиотеки и C# генерируется на лету на основе кода С++ или ещё что-то подобное.
CMake в итоге тот же MSBuild и использует, как я понимаю, значит все причуды xml на месте, но спрятаны за обёрткой.
Про EF тоже говорят, что можно в SQL не лезть и само сгенерируется, а по факту лучше всё перепроверять, а то там нагенерируется, что волосы дыбом встают.

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

K>Мне видится логичным отдельно собирать более классическими инструментами проект на С++ и отдельными инструментами на C#

Ну вот для C++ CMake генерирует проект студии на Windows, а на Linux например Makefile.
И соответственно раз и C++ и C# проекты будут в одном solution — между ними будут правильные зависимости.

K>а потом уже третьим инструментом для деплоя всё в кучу согребать.

А зачем третий инструмент, если CMake справляется и с тестами (CTest/CDash) и с упаковкой (CPack)?

K>Можно конечно всё в один репозиторий засунуть и собирать одним файликом, но как-то больше на кашу похоже, в которой потом сложно разобраться.

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

K>Ну, может конечно там проект на C# — это обёртки для вызова функций из С++библиотеки и C# генерируется на лету на основе кода С++ или ещё что-то подобное.

Он может как генерироваться, так и быть написан в ручную. В чём разница в обсуждаемом контексте?

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

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

K>Про EF тоже говорят, что можно в SQL не лезть и само сгенерируется, а по факту лучше всё перепроверять, а то там нагенерируется, что волосы дыбом встают.

Вот как-то не приходилось лезть во внутрь файлов студийных проектов сгенерированных CMake (VS2003 — VS2015) — оно просто работало, я даже не помню что там внутри. Результирующие опции компиляции посмотреть — да, но это больше для отладки своих настроек и проектных файлов, а не того как именно CMake нагенерировал.

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

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

S>>>>Не очень понимаю, вам это всё зачем? Вы хотите порождать проект автоматически?

N>Раз уж речь, про cmake, то он как раз и используется для генерации проектов, включения и исключения их массово.
N>Например, есть большой проект OoenCV. В максимальной комплектации он вполне может включать в себя тысячу проектов. Отключать можно что угодно: тесты, примеры, проекты для интеграции с Питоном, Java, Julia... Можно отдельные модули. Если нет зависимости для какого-то модуля, то автоматически отключаются все, которые зависят от него. Можно собирать все модули статически, можно каждый в своей dll, можно все в одной большой dll.
N>Можно для windows, Linux, mac, android, ios...Можно выбирать тулчейны для сборки. Он сам скачивает зависимости с гитхаба. Или данные (веса нейросетки), или библиотеки (Intel IPP). Собирает, копирует, делает install.
Ну, так это всё актуально для старпёрских платформ типа С++, где нужно собирать под каждый таргет на стороне разработчика.
Дотнет от этого избавлен — компилируем то, что нужно — и всё. Если нужен конкретный проект — компилируем конкретный проект. Если хотим прогнать CI — скомпилировать и проверить все тесты, примеры, и т.п. — то собираем solution. Динамически порождать .csproj — вот оно зачем?

Потому то у меня и возникает вопрос — какую задачу решает ТС?

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

EP>>И соответственно раз и C++ и C# проекты будут в одном solution — между ними будут правильные зависимости.
K>Зачем их в один солюшен пихать?
K>Ну, так конечно быстрее пилить изменения и там и там одновременно.

Ну да, быстрее и удобнее

K>Но не "правильнее" ли отдельно собирать dll на С++, прописывать для неё тесты и т.п., а в C# уже подсовывать протестированную библиотеку и не пересобирать её каждый раз?

C++ библиотека покрыта тестами, C# библиотека/приложение также покрыты тестами в том числе в месте интеграции с C++ библиотекой.
Изменение в C++ библиотеке означает что нужно как минимум прогнать все тесты заново, а ещё возможно и подцепить новое ABI.
Кто в предлагаемом тобой варианте будет это всё дирежировать? Зачем какой-то отдельный дирижёр если уже есть CMake?

K>А если у библиотеки есть обёртки на десятки языков, то все их в один солюшен пихать и каждому разработчику настраивать полностью окружение, хотя он кроме C# ничего и не знает и пилит только библиотеку на этом языке?

1. Настраивать всё окружение не обязательно, CMake проверит что доступно и позволит отключить то для чего не хватает зависимостей.
2. CMake файлы определяющие C# проекты могут быть использованы как в составе большого солюшена, где собираются все необходимые C++ библиотеки как отдельные проекты, так и совершенно отдельно, используя готовую dll без её исходников (а-ля imported target).

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

K>Пока я вижу странный вопрос и никто на него не ответил, значит никто не знает, корректно ли работает CMake с .NET 5

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

K>Ну, если в команде все всем занимаются, то можно не париться, а если я разработчик C#, то зачем мне в солюшене проекты на C++ и зачем я их у себя буду собирать, если не меняю ничего там?

Менять могут другие члены команды, изменения которых тебе прилетят на следующем git pull. Но если хочется отдельный проект с бинарными зависимостями то и этот вариант доступен, причём доступен одновременно с вариантом всё-в-одном-solution.

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

А тут без разницы генерируется или просто зависит от API. И там и там нужно предоставить артефакты зависимости в каком либо виде, будь то .dll или сгенерированные куски C#. И там и там эти артефакты будут зависеть от версии C++ кода. И там и там весь C++ код иметь не обязательно, а можно лишь предоставлять эти артефакты.

K>>>CMake в итоге тот же MSBuild и использует, как я понимаю, значит все причуды xml на месте, но спрятаны за обёрткой.
EP>>Эн нет, фичи CMake не должны мэппиться один в один. Там где в CMake меня будут в циклы, функции, переменные, в результирующем выхлопе всё это будет развёрнуто/заинлайненно, и та система сборки что в бэкенде может и не поддерживать всё это.
K>либо что-то хитрое можно было бы сделать на xml и проект собирался бы 5 минут, а в итоге будет что-то заинлайнено так, как решили разработчики CMake и вот уже сборка 15 минут.

С чего бы это? Ну разве что MSBuild может зависнуть на 10 минут при парсинге xml.
Таргреты-то будут по сути те же самые — независимо от того заинлайнил ли их CMake в .xml, либо программист раскорячился и сделал вложенный цикл на .xml.

K>Я как бы не против CMake и вероятно кому-то оно действительно нужно и полезно. Вопрос насколько он популярен в рамках .NET, как оперативно в него новые штуки добавляют, насколько большое комьюнити, чтобы искать и фиксить баги,... Собственно я сугубо из-за этого за более популярные решения. Ни разу просто не слышал, чтобы CMake шарписты использовали, собственно из-за этой темы только узнал, что он оказывается в принципе поддерживает проекты под .NET.

Используют обычно там где есть проекты на разных языках.
Ну и может кто уже умеет в CMake, то ему проще оставаться в его рамках, получать лаконичное определение проекта, и не тратить время на изучение схемы xml/gui настроек, которые за пределами сужающейся экосистемы MS не пригодятся от слова совсем.

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

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

EP>>>И соответственно раз и C++ и C# проекты будут в одном solution — между ними будут правильные зависимости.
K>>Зачем их в один солюшен пихать?
K>>Ну, так конечно быстрее пилить изменения и там и там одновременно.

EP>Ну да, быстрее и удобнее

Ну, а SVN удобнее, чем git, т.к. там две кнопки практически — update и commit (если ветками и т.п. штуками не пользоваться).

K>>Но не "правильнее" ли отдельно собирать dll на С++, прописывать для неё тесты и т.п., а в C# уже подсовывать протестированную библиотеку и не пересобирать её каждый раз?

EP>C++ библиотека покрыта тестами, C# библиотека/приложение также покрыты тестами в том числе в месте интеграции с C++ библиотекой.
EP>Изменение в C++ библиотеке означает что нужно как минимум прогнать все тесты заново, а ещё возможно и подцепить новое ABI.
EP>Кто в предлагаемом тобой варианте будет это всё дирежировать? Зачем какой-то отдельный дирижёр если уже есть CMake?

Ну, при изменении C++ плевать на C# и тестировать только С++.
C# плевать на тесты С++ и проверяется только библиотека C# и куски интеграции с С++, а точнее с той версией, на которую сейчас референс сделан.
Этим всем может и CMake заниматься, но зачем в кучу пихать оба проекта

K>>А если у библиотеки есть обёртки на десятки языков, то все их в один солюшен пихать и каждому разработчику настраивать полностью окружение, хотя он кроме C# ничего и не знает и пилит только библиотеку на этом языке?

EP>1. Настраивать всё окружение не обязательно, CMake проверит что доступно и позволит отключить то для чего не хватает зависимостей.
EP>2. CMake файлы определяющие C# проекты могут быть использованы как в составе большого солюшена, где собираются все необходимые C++ библиотеки как отдельные проекты, так и совершенно отдельно, используя готовую dll без её исходников (а-ля imported target).

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

Значит я у себя соберу только С++ проект, он выполнит тесты только для него, скажет, что всё нормально, а у разработчика C# ничего не соберётся, т.к. я в функцию добавил входной параметр, о чём код на C# не знает ещё?

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

EP>А тут без разницы генерируется или просто зависит от API. И там и там нужно предоставить артефакты зависимости в каком либо виде, будь то .dll или сгенерированные куски C#. И там и там эти артефакты будут зависеть от версии C++ кода. И там и там весь C++ код иметь не обязательно, а можно лишь предоставлять эти артефакты.

Я к подобным вещам отношусь просто не как нужно, а как можно, но не нужно.
Если есть возможность разделить, то лучше пусть будет всё отдельно, а то кто-нибудь ненужную зависимость добавит, сломает то, куда вообще не должен был лезть,...

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

S>Повторю вопрос: вам это всё зачем?
S>Обычно проект создаётся один раз. А потом много лет развивается. Поэтому не очень важно, как именно устроено порождение проекта.
S>Мне интересен ваш сценарий от начала и до конца: что именно вы хотите автоматизировать и почему. Конкретные инструменты — это конкретные инструменты, их же под задачу подбирают, а не наоборот.

Вот уж никак не ожидал, что такой простой вопрос (subj, и правильный ответ очевидно "нет") вызовет такой накал страстей

Знатоки правильно предположили, что проект кросс-платформенный и на 90% написан на C++, доля C# в нём невелика.
.NET Framework тоже не сразу, kitware потребовалось много лет, но C# стал поддерживаться из коробки. На данный момент файлы .net core проектов генерируются CMake с использованием file(APPEND ...), но это совсем не то, за что мы его любим

Потому и спросил, вдруг я чего-то не знал...

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

BB>Вот просто как в .net Framework, но только с чем-нибудь вроде set(DOTNET_TARGET_FRAMEWORK "net5.0") в CMakeLists, а потом `cmake .` и готово? Безо всяких там сгенериривать один проект, а потом руками/powershell-скриптом его исправить, и прочих танцев с бубном?

Кажется что я встречал нечто подобное и даже без использования CMake от команды Xamarin. Но, к сожалению, по ключевым словам не гуглится. Идея там была, чтобы генерировать sln/csproj по существующим папкам в репозитории и сам "базовый" проект был обычным msbuild скриптом.
Может кто подскажется как это называется?

--
С Уважением, Andir!

using( RSDN@Home 1.0.0 alpha 5 rev. 0) { /* Работаем... */ }

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

EP>>>>И соответственно раз и C++ и C# проекты будут в одном solution — между ними будут правильные зависимости.
K>>>Зачем их в один солюшен пихать?
K>>>Ну, так конечно быстрее пилить изменения и там и там одновременно.
EP>>Ну да, быстрее и удобнее

K>Ну, а SVN удобнее, чем git, т.к. там две кнопки практически — update и commit (если ветками и т.п. штуками не пользоваться).

Нет, git удобнее. Даже когда upstream был cvs/svn — я использовал git.
Но не ясен твой поинт. Вот нужно делать изменения и там и там — расширили/изменили API C++ библиотеки — обновили пример в C#, сразу всё проверили.
Твоё предложение? Сделать неудобно и медленно? Ради чего?

K>Этим всем может и CMake заниматься, но зачем в кучу пихать оба проекта

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

EP>>1. Настраивать всё окружение не обязательно, CMake проверит что доступно и позволит отключить то для чего не хватает зависимостей.
EP>>2. CMake файлы определяющие C# проекты могут быть использованы как в составе большого солюшена, где собираются все необходимые C++ библиотеки как отдельные проекты, так и совершенно отдельно, используя готовую dll без её исходников (а-ля imported target).
EP>>То есть выбор делать не нужно, доступен и тот и другой вариант одновременно, из одного и того же определения проекта (точнее кода CMake).
K>Значит я у себя соберу только С++ проект, он выполнит тесты только для него, скажет, что всё нормально, а у разработчика C# ничего не соберётся, т.к. я в функцию добавил входной параметр, о чём код на C# не знает ещё?

Если собирать их отдельно (за что ты так ратуешь, и что в том числе поддерживается CMake), то C# код будет зависеть от конкретной версии/ревизии — и даже если master C++ уйдёт вперёд, старые .dll-ки никуда не денутся и продолжать работать, то есть внезапно старые версии C# кода не сломаются

K>Если есть возможность разделить, то лучше пусть будет всё отдельно,

Ну а в чём разница с двумя C# проектами в одном солюшн, где один зависит от другого?
Или ты вообще против solution?

K>а то кто-нибудь ненужную зависимость добавит, сломает то, куда вообще не должен был лезть,...

шта?

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

EP>Проектный файл выраженный на языке CMake получается достаточно лаконичным. За счёт того что можно определять функции — можно легко убирать boilerplate из проектного файла и делать рефакторинг по мере роста проекта (ага, уже предвосхищаю недоумение — как так рефакторить проектный файл — а вот как обычный код).

Ты так рассказываешь, как будто в msbuild всего этого нет.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

csharp_library(
    name = "service_proto.dll",
    srcs = [":service_proto_gen_cs"],
    deps = [
        "@core_sdk_stdlib//:libraryset",
        "@google.protobuf//:lib",
        "@grpc.core.api//:lib",
        "@grpc.core//:lib",
    ],
)

Связать две либы на с# и на c++ можно как-то так:

cc_library(
   name = "dummy_lib_cpp",
   ....
)

csharp_library(
   name = "dummy_lib_cs",
   ....
   deps = [
      ":dummy_lib_cpp"
   ]
)

т.е. перед сборкой либы на с# будет собрана либа на c++ (если она уже не была собрана ранее)

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

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

Обычно одни люди пишут на С++, а другие на шарпе, в чём профит от того, что они будут работать в одном солюшене?
Если в команде конечно не просто фулстек, а профи на двух языках и это не планируется менять, то можно и в один солюшен засунуть

Я и проекты на шарпе предпочитаю разделять.
Ну, допустим, есть какая-то своя библиотека для реализации MVVM, если проект, который её использует.
Я разнесу это по разным репозиториям и солюшенам, т.к. завтра у меня может появиться ещё один проект, которому будет нужен MVVM и идеологически это всё не должно быть в куче.
Если это какие-то достаточно тесно связанные библиотеки, то безусловно удобнее будет их в одном солюшене держать, а то получится, что нужно в модели тип свойства с int на long поменять, а ты будешь сначала библиотеку с моделью собирать, публиковать какой-нибудь Nuget-пакет с новой версией, обновлять в другом солюшене с ViewModel, там менять тип, а потом ещё раз уже по View то же самое делать.

EP>>>1. Настраивать всё окружение не обязательно, CMake проверит что доступно и позволит отключить то для чего не хватает зависимостей.
EP>>>2. CMake файлы определяющие C# проекты могут быть использованы как в составе большого солюшена, где собираются все необходимые C++ библиотеки как отдельные проекты, так и совершенно отдельно, используя готовую dll без её исходников (а-ля imported target).
EP>>>То есть выбор делать не нужно, доступен и тот и другой вариант одновременно, из одного и того же определения проекта (точнее кода CMake).
K>>Значит я у себя соберу только С++ проект, он выполнит тесты только для него, скажет, что всё нормально, а у разработчика C# ничего не соберётся, т.к. я в функцию добавил входной параметр, о чём код на C# не знает ещё?

EP>Если собирать их отдельно (за что ты так ратуешь, и что в том числе поддерживается CMake), то C# код будет зависеть от конкретной версии/ревизии — и даже если master C++ уйдёт вперёд, старые .dll-ки никуда не денутся и продолжать работать, то есть внезапно старые версии C# кода не сломаются

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

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

EP>>Проектный файл выраженный на языке CMake получается достаточно лаконичным. За счёт того что можно определять функции — можно легко убирать boilerplate из проектного файла и делать рефакторинг по мере роста проекта (ага, уже предвосхищаю недоумение — как так рефакторить проектный файл — а вот как обычный код).
НС>Ты так рассказываешь, как будто в msbuild всего этого нет.

Давай сравним лаконичность. Например вложенный цикл:

foreach(date 20210101 20210701 20210712)
    foreach(x a b c)
        message(STATUS "${date} ${x}")
    endforeach()
endforeach()

Здравствуйте, 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>Давай сравним лаконичность.

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

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

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

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

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

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

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

Здравствуйте, 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>Ага, прикольно, а предыдущем предложении ты объясняешь коллеге который таки не подозревает.

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

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

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

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

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

Здравствуйте, 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 его всё-равно бесполезно. ))

<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>

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

Здравствуйте, 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 можно сделать все ровно то же.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

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

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

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

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

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

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

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

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

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

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

	От:	Ночной Смотрящий
	Дата:	13.07.21 08:21
	Оценка:	76 (1) +1

	От:	VladCore
	Дата:	06.07.21 02:14
	Оценка:	+1

	От:	Evgeny.Panasyuk
	Дата:	11.07.21 07:18
	Оценка:	+2

От:	Sinclair	https://github.com/evilguest/
Дата:	12.07.21 14:18
Оценка:	+2

От:	_NN_	www.nemerleweb.com
Дата:	05.07.21 05:53
Оценка:	+1

От:	Nuzhny	https://github.com/Nuzhny007
Дата:	11.07.21 06:05
Оценка:	+1

	От:	Mystic Artifact
	Дата:	11.07.21 01:45
	Оценка:

От:	Andir	http://twitter.com/AndirNotes
Дата:	11.07.21 21:41
Оценка:

	От:	BigBoss
	Дата:	04.07.21 22:00
	Оценка:

	От:	BigBoss
	Дата:	10.07.21 00:11
	Оценка:

	От:	BigBoss
	Дата:	10.07.21 23:27
	Оценка: