Search
Write a publication
Pull to refresh

Comments 16

Круто.

Но я даже не помню когда я что-то там редактировал.

🥺

Когда переименовывается проект, а папку оно не меняет, и тогда нужно редактировать.

А еще бывали хвосты архитектуры конфигурации плюсов попадали, их проще было ручками удалить.

Или когда исправляешь конфликты. Кто-то на мастере добавил новый проект, и ты добавил новый проект.

Поэтому нечего build файлы пихать в репозиторий. Там должен лежать CMakeLists.txt и все. Лично мое мнение. И не нужно будет ничего руками редактировать.

Я тоже могу выдумать причины для ручного редактирования. А если заплатят так и ещё обосную.

😊 Но в 99.99% меня не волнует как и что там написано.

И всё?! Да, это весь файл решения.

Не вижу активных конфигураций.

<Solution>
  
  <!-- Solution configuraions -->
  <Configurations>
    <Platform Name="Win32" />
    <Platform Name="x64" />
  </Configurations>
  
  <!-- Solution folder(s) -->
  <Folder Name="/Solution Items/">
    <File Path="Directory.Build.props" />
    <File Path="Directory.Build.targets" />
  </Folder>

  <!-- This project supports and build all solution configurations (default) -->
  <Project Path="Project1.vcxproj" />
  
  <!-- This project supports only Win32 platform and excluded from x64 -->
  <Project Path="Project2.vcxproj">
    <Platform Project="Win32" />
    <Build Solution="*|x64" Project="false" />
  </Project>

</Solution>

В общем, жить можно вроде.

Странно, что новое расширение назвали slnx, а не slnproj

XML, мягко говоря, тоже не очень дружелюбен к читателю. Слишком он многословный. Могли бы и JSON выбрать.

Каков вообще смысл сейчас использовать vcproj/sln файлы? Visual Studio давно уже поддерживает CMake, который значительно более прост в редактировании и чтении, да к тому же не прибит гвоздями к одной конкретной IDE.

Существуют другие языки, не только C++. В статье приводится пример для проектов на C#, vcxproj упоминается только в комментариях.

CMake, который значительно более прост в редактировании и чтении

Тьюринг-полный язык, для которого есть и настоящий отладчик в том числе, у вас проще декларативного файла конфигурации?

Если Cmake использовать декларативно (только часть его функционала), то он лаконичнее XML. Он ведь создавался для написания руками, а XML же больше машиночитаемый, чем человекочитаемый.

Тьюринг-полнота тоже полезна, местами. Если что-то надо сделать по хитрому условию в cmake это просто делается. С проектами Visual Studio же начинаются пляски с бубном, вроде поиска неочевидных пунктов в меню настроек проекта или того хуже, с прикручиванием внешних bat или powershell скриптов.

Sign up to leave a comment.