Блог

В настоящее время я пытаюсь улучшить пользовательский интерфейс CMake в Microsoft Visual Studio (MSVS) 2019 с помощью нашей системы сборки на основе соглашения о перенастройке конфигурации на основе CMake.

До MSVC 2019 мы всегда использовали генератор «MSBuild» (например "Visual Studio 2017" ). Но поскольку Microsoft заявляет, что более поздние обновления MSV могут открывать существующий CMakeCache.txt , я хотел попробовать эту функцию MSVS.

Чего я хотел бы добиться: заставить MSVS 2019 «понимать» CMakeCache.txt файлы с помощью генератора сборки "Ninja Multi-Config" .

В настоящее время наша система сборки генерирует CMakeSettings.json файл (в том же каталоге, CMakeLists.txt что и файл) на этапе настройки:

 {
  "configurations": [
    {
      "name": "x64-windows-msvc1927-static-md-Debug",
      "cacheRoot": "C:/_bld",
      "cmakeExecutable": "E:/dev/native/cmake/cmake-3.18.2-x64/bin/cmake.exe",
      "configurationType": "Debug"
    },
    {
      "name": "x64-windows-msvc1927-static-md-Release",
      "cacheRoot": "C:/_bld",
      "cmakeExecutable": "E:/dev/native/cmake/cmake-3.18.2-x64/bin/cmake.exe",
      "configurationType": "Release"
    },
    {
      "name": "x64-windows-msvc1927-static-md-RelWithDebInfo",
      "cacheRoot": "C:/_bld",
      "cmakeExecutable": "E:/dev/native/cmake/cmake-3.18.2-x64/bin/cmake.exe",
      "configurationType": "RelWithDebInfo"
    }
  ]
}
  

Зачем мы это делаем? Мы должны явно установить "cmakeExecutable" , в противном случае MSVS использует версию CMake, поставляемую с MSVS. Это не удается, потому что мы используем версию v3.18 (и не хотим полагаться на две разные версии CMake для создания программного обеспечения).

Все выглядит нормально, потому что все три конфигурации сборки отображаются под полем со списком «конфигурация сборки» в среде разработки MSVS.

Но независимо от того, что выбрано, IDE всегда создает и запускает конфигурацию Debug сборки. Выбор другой конфигурации сборки вообще не имеет никакого эффекта.

Я боюсь, что (пока) невозможно достичь цели, указанной выше, с помощью MSVS, потому что он просто не понимает "Ninja Multi-Config" генератор.

Дело в том, что я не могу изменить генератор на "Ninja" , потому что это вызовет предупреждение CMake для существующего кэша.

1. Должен ли я использовать "Ninja" генератор (вместе с различными деревьями сборки) в первую очередь?
2. Есть ли какое-либо реальное решение моей проблемы использования «Ninja» в качестве генератора с несколькими конфигурациями в MSVS 2019?
3. Если ответ на вопрос 1 «да» или на вопрос 2 «нет»: не следует ли упростить использование генератора "Visual Studio 2019" ? Я не вижу никакого преимущества UX, если тогда не использовать этот генератор.

Используется следующая среда:

• CMake v3.18.2
• Microsoft Visual Studio 2019 v16.7.5
• Ninja 1.10.1

CMake выше и автор генератора Ninja Multi-Config здесь. Несколько вещей:

1. Как вы обнаружили, вы не можете изменить генератор для существующего дерева. Например, если дерево было построено с помощью Ninja, вы не сможете позже изменить его на Ninja Multi-Config. Лучшее, что можно сделать, это запустить новое дерево сборки — либо стереть старое и начать заново, либо запустить новое в другом каталоге.
2. AFAIK, Microsoft еще не добавила поддержку Ninja Multi-Config. Я, конечно, надеюсь, что в какой-то момент они это сделают, потому что это генератор, который мы рекомендуем для IDE, использующих CMake. Однако на самом деле это не имеет значения, потому что…
3. Да, я почти уверен, что Visual Studio может открыть CMakeCache.txt с помощью сгенерированного решения Visual Studio. Даже если это невозможно, вы, конечно, можете напрямую открыть решение Visual Studio.