Здравствуйте, 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 с нужными ключами сборки, выходной папкой и т.п.
Здравствуйте, karbofos42, Вы писали:
K>Есть подозрение, что если вместо CMake взять MSBuild и так же с ним заморочиться, то окажется, что всё это можно сделать и на xml, но это ж разбираться надо, а CMake кто-то когда-то уже изучил и зачем что-то новое учить
А преимущества разные могут быть. Например этот .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 нагенерировал.
Здравствуйте, 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.
Здравствуйте, 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 скриптом.
Может кто подскажется как это называется?
Здравствуйте, 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-екзешник, я почему-то себе представить не могу.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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>а то кто-нибудь ненужную зависимость добавит, сломает то, куда вообще не должен был лезть,...
Здравствуйте, Sinclair, Вы писали:
S>Я по-прежнему не понимаю, для чего потребовалось именно порождать проект C#.
Для начала нужно разобраться что же делает CMake.
S>Это на С++ нет понятия "проекта", и поэтому CMake и прочие инструменты вынуждены изгаляться, восстанавливая проектный файл на лету.
CMake не восстанавливает проектный файл. Определение проекта записывается на языке CMake — это первоисточник.
S>В C# не бывает такого, что на винде применяем .csproj, а на линуксе — какие-нибудь мейк-файлы.
Ну и здорово. Даже если бэкэнд всегда один, и софт совсем не кроссплатформенный — CMake он сам по себе удобен. Удобнее студийных xml'ек, удобнее голого Make'а.
Проектный файл выраженный на языке CMake получается достаточно лаконичным. За счёт того что можно определять функции — можно легко убирать boilerplate из проектного файла и делать рефакторинг по мере роста проекта (ага, уже предвосхищаю недоумение — как так рефакторить проектный файл — а вот как обычный код).
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Проектный файл выраженный на языке CMake получается достаточно лаконичным. За счёт того что можно определять функции — можно легко убирать boilerplate из проектного файла и делать рефакторинг по мере роста проекта (ага, уже предвосхищаю недоумение — как так рефакторить проектный файл — а вот как обычный код).
Ты так рассказываешь, как будто в msbuild всего этого нет.
Здравствуйте, 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 файл проекта — занахрена? С учётом того, что он при каждой сборке один и тот же...
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, BigBoss, Вы писали:
BB>Вот просто как в .net Framework, но только с чем-нибудь вроде set(DOTNET_TARGET_FRAMEWORK "net5.0") в CMakeLists, а потом `cmake .` и готово? Безо всяких там сгенериривать один проект, а потом руками/powershell-скриптом его исправить, и прочих танцев с бубном?
А использование cmake критично? Есть Bazel. Именно C# собирать не приходилось, т.к. использую bazel для с++, но он умеет много всякого.Пример кусочка для С#:
Здравствуйте, 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()