[develop2] Missing compiler.runtime setting

[simonimpey]

I am trying to upgrade a project from Conan 1.x to 2.x. When building using Visual Studio 2022 via it's native CMake support I am running into the following issue:

1> [CMake] ======== Finalizing install (deploy, generators) ========
1> [CMake] ERROR: conanfile.py: Invalid ID: Invalid: 'settings.compiler.runtime' value not defined
1> [CMake] CMake Error at Windows/MSVC/x64/Release/conan_provider.cmake:197 (message):
1> [CMake] Conan install failed='6'

In the Conan 1.x CMake file there were routine(s) for determining the compiler runtime in Visual Studio but these do not appear to be present in the new conan_provider.cmake. What is the recommended method for supplying this setting in via Conan CMake in version 2.x?

[jcar87]

Hi @simonimpey - thank you for reporting this issue.

The new integration (develop2) currently expects this information to be provided in the default profile (and if the default profile does not exist, it creates it on the fly). There is indeed room for more added robustness that we are working on, but in the mean time, is this not the case for you?

I would imagine this could be a problem if you already have a default profile that doesn't define compiler.runtime. Additionally, if you didn't have a default profile previously defined, is there any chance cmake was invoked from inside a Visual Studio shell (vcvars)?

[simonimpey]

Hi,

I suspect that cmake is indeed being run from withing a VS shell as it is being run by VS itself, we use VS 2022's native CMake support to simply open the CMakeLists file in Visual Studio.

I think though that this is something that should be detected on the fly if possible as it should be possible for different projects on the same system to use different runtime settings.

In the short term I shall simply ensure that this is set in the default profile.

[jcar87]

Hi @simonimpey - I see, this is probably relevant if CMake is being run with Visual Studio. I should be able to reproduce this, will give this is a go and see how we can best solve this

[fklebert]

I can confirm that this only happens if you run it via the VSCode integration of CMake.

When running the conan profile detect step from the CMake within VSCode's cmake integration, it only creates a default profile with

[cmake] Detected profile:
[cmake] [settings]
[cmake] arch=x86_64
[cmake] build_type=Release
[cmake] os=Windows

Running the exact same command (the cmake call that VSCode produces, e.g. "C:\Program Files\CMake\bin\cmake.EXE" --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -SC:/DATA/Win_Development/zswag -Bc:/DATA/Win_Development/zswag/build -G "Visual Studio 17 2022" -T host=x64 -A x64 in my case) on the normal Windows command line correctly produces

[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.version=193
os=Windows

Once that is correctly run from the normal command line, everything works nicely also from within VSCode as we have a correct default profile.

However everything also works fine if you run conan profile detect from anywhere on your system manually before using the VSCode cmake integration the first time.
Still puzzling me a bit, why that is...

[jcar87]

Hi @simonimpey - I've tried to reproduce this on my end, but have been unable to. If I open the project directly from Visual Studio (where the VS IDE invokes CMake, and cmake invokes Conan, and there is no default profile) - it seems to work fine.

conan profile detect should generate a profile like this:

[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.version=193
os=Windows

The compiler.runtime is set to be added in the profile detection logic in the Conan client for the msvc compiler - so I wonder if the issue lies elsewhere.

Are you still able to reproduce this issue? Could you paste the contents of your default profile, or would you be able to remove/rename the default profile from the profiles folder, to force cmake-conan to generate it again?
And if you could post the entire output of the log from Visual Studio, that would be great, thanks!

[jcar87]

I can confirm that this only happens if you run it via the VSCode integration of CMake.

HI @fklebert - thank you for reporting this as well. This seems to be an entirely different issue altogether, where no compiler is detected at all. If you could give us some pointers on how to set up VSCode to reproduce this, that would be great!

[fklebert]

I do not do really much else than you obviously tried already.

1. delete the default profile from <user_home>/.conan2/profiles so that this directory is completely empty.
2. Startup VSCode and open a project that includes these lines in the top CMake (having the option in VSCode CMake enabled that it automatically configures on start)

cmake_minimum_required(VERSION 3.24)
# Add conan 2.0 support
set(CMAKE_PROJECT_TOP_LEVEL_INCLUDES ${CMAKE_CURRENT_SOURCE_DIR}/cmake/conan-provider.cmake)

I get the following output:

[variant] Loaded new set of variants
[kit] Successfully loaded 4 kits from C:\Users\...\AppData\Local\CMakeTools\cmake-tools-kits.json
[proc] Executing command: "C:\Program Files\CMake\bin\cmake.EXE" --version
[proc] Executing command: chcp
[visual-studio] Patch Windows SDK path from C:\Program Files (x86)\Windows Kits\10\bin\x64 to C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64 for C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Auxiliary\Build\vcvarsall.bat
[main] Configuring project: zswag 
[proc] Executing command: "C:\Program Files\CMake\bin\cmake.EXE" --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Release -SC:/DATA/Win_Development/zswag -Bc:/DATA/Win_Development/zswag/build -G "Visual Studio 17 2022" -T host=x64 -A x64
[cmake] Not searching for unused variables given on the command line.
[cmake] -- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.22621.
[cmake] -- CMake-Conan: first find_package() found. Installing dependencies with Conan
[cmake] -- CMake-Conan: Checking if a default profile exists
[cmake] ERROR: Profile not found: default
[cmake] -- CMake-Conan: The default profile doesn't exist, detecting it.
[cmake] CC and CXX: cl.exe, cl.exe 
[cmake] ERROR: Not able to automatically detect 'cl.exe' version
[cmake] No compiler was detected (one may not be needed)
[cmake] WARN: This profile is a guess of your environment, please check it.
[cmake] Detected profile:
[cmake] [settings]
[cmake] arch=x86_64
[cmake] build_type=Release
[cmake] os=Windows
[cmake] 
[cmake] WARN: The output of this command is not guaranteed to be stable and can change in future Conan versions.
[cmake] WARN: Use your own profile files for stability.
[cmake] Saving detected profile to C:\Users\...\.conan2\profiles\default
[cmake] -- CMake-Conan: cmake_system_name=Windows
[cmake] -- CMake-Conan: cmake_system_processor=x86_64
[cmake] -- CMake-Conan: CMake compiler=MSVC
[cmake] -- CMake-Conan: CMake compiler version=19.33.31630.0
[cmake] -- CMake-Conan: [settings] compiler=msvc
[cmake] -- CMake-Conan: [settings] compiler.version=193
[cmake] -- CMake-Conan: Creating profile C:/DATA/Win_Development/zswag/build/conan_host_profile
[cmake] -- CMake-Conan: Profile: 
[cmake] include(default)
[cmake] [settings]
[cmake] arch=x86_64
[cmake] os=Windows
[cmake] compiler=msvc
[cmake] compiler.version=193
[cmake] compiler.cppstd=17
[cmake] [conf]
[cmake] tools.cmake.cmaketoolchain:generator=Visual Studio 17 2022
[cmake] 
[cmake] -- CMake-Conan: Installing both Debug and Release
[cmake] -- CMake-Conan: conan install C:/.../zswag -of=C:/.../zswag/build/conan -pr;C:/.../zswag/build/conan_host_profile;-s;build_type=Release;--build=missing;-g;CMakeDeps
[cmake] 
[cmake] ======== Input profiles ========
[cmake] Profile host:
[cmake] [settings]
[cmake] arch=x86_64
[cmake] build_type=Release
[cmake] compiler=msvc
[cmake] compiler.cppstd=17
[cmake] compiler.version=193
[cmake] os=Windows
[cmake] [conf]
[cmake] tools.cmake.cmaketoolchain:generator=Visual Studio 17 2022
[cmake] 
[cmake] Profile build:
[cmake] [settings]
[cmake] arch=x86_64
[cmake] build_type=Release
[cmake] os=Windows
[cmake] 
[cmake] 
[cmake] ======== Computing dependency graph ========
[cmake] Graph root
[cmake]     conanfile.txt: C:/.../zswag\conanfile.txt
[cmake] Requirements
[cmake]     fmt/10.0.0#dd5e3eb81b512a1bb34a5aab88a07e82 - Cache
[cmake]     keychain/1.2.1#0361cefea79084f9ec016ee869a5779d - Cache
[cmake]     openssl/1.1.1t#7d9fc949345908e1b8609d9d9f528a08 - Cache
[cmake]     pybind11/2.10.4#dd44c80a5ed6a2ef11194380daae1248 - Cache
[cmake]     spdlog/1.11.0#8b4bd1da26e0ec97698369d6224d93bf - Cache
[cmake] Build requirements
[cmake]     msys2/cci.latest#567331f1604f3c584f04feade960f06e - Cache
[cmake]     nasm/2.15.05#799d63b1672a337584b09635b0f22fc1 - Cache
[cmake]     strawberryperl/5.32.1.1#8f83d05a60363a422f9033e52d106b47 - Cache
[cmake] 
[cmake] ======== Computing necessary packages ========
[cmake] Requirements
[cmake]     fmt/10.0.0#dd5e3eb81b512a1bb34a5aab88a07e82:304ec0516503b115fe02862e40efb507a6e64abc - Invalid
[cmake]     keychain/1.2.1#0361cefea79084f9ec016ee869a5779d:96a7dcdf282ccad6595b274378d5a14331e06f65 - Invalid
[cmake]     openssl/1.1.1t#7d9fc949345908e1b8609d9d9f528a08:f8dbcb081e4d5688ee366a5f8c7fe8f5bfe5b7c7 - Invalid
[cmake]     pybind11/2.10.4#dd44c80a5ed6a2ef11194380daae1248:da39a3ee5e6b4b0d3255bfef95601890afd80709#123c7aa30a672ba817d5a10fb563c4b9 - Cache
[cmake]     spdlog/1.11.0#8b4bd1da26e0ec97698369d6224d93bf:bb52a8f0d514e0570121860cac938388d1d9d5d6 - Invalid
[cmake] Build requirements
[cmake] Skipped binaries
[cmake]     msys2/cci.latest, nasm/2.15.05, strawberryperl/5.32.1.1
[cmake] 
[cmake] ======== Installing packages ========
[cmake] ERROR: There are invalid packages:
[cmake] fmt/10.0.0: Invalid: 'settings.compiler.runtime' value not defined
[cmake] keychain/1.2.1: Invalid: 'settings.compiler.runtime' value not defined
[cmake] spdlog/1.11.0: Invalid: 'settings.compiler.runtime' value not defined
[cmake] openssl/1.1.1t: Invalid: 'settings.compiler.runtime' value not defined
[cmake] CMake Error at cmake/conan-provider.cmake:206 (message):
[cmake]   Conan install failed='6'
[cmake] Call Stack (most recent call first):
[cmake]   cmake/conan-provider.cmake:275 (conan_install)
[cmake]   CMakeLists.txt:36 (find_package)
[cmake] 
[cmake] 
[cmake] -- Configuring incomplete, errors occurred!
[cmake] See also "C:/.../zswag/build/CMakeFiles/CMakeOutput.log".
[cmake] See also "C:/.../zswag/build/CMakeFiles/CMakeError.log".
[proc] The command: "C:\Program Files\CMake\bin\cmake.EXE" --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Release -SC:/.../zswag -Bc:/.../zswag/build -G "Visual Studio 17 2022" -T host=x64 -A x64 exited with code: 1
[visual-studio] Patch Windows SDK path from C:\Program Files (x86)\Windows Kits\10\bin\x64 to C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64 for C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Auxiliary\Build\vcvarsall.bat

It seems to correctly guess the compiler, only the runtime info is missing.

The fix on my side is to delete the wrongly generated default profile and run conan profile detect manually. Then all is good.
Let me know if you need any more details on my CMakeTools extension or anything.

EDIT: Forgot to add that although from the cmake output it looks like it got the compiler right, it does not store it in the default profile on disk. The content of the stored profile after the VSCode CMake call is:

[settings]
arch=x86_64
build_type=Release
os=Windows

[jcar87]

HI @fklebert - thank you for providing the log. In this case I have a strong suspicion that the CC and CXX environment variables are set to point to cl.exe and that Conan cannot currently derive the compiler and version from this. In normal circumstances it simply tries to assume a default of the most recent version of Visual Studio found on the system, but in this case since it already has a compiler set via environment, it would try to do that.

cmake-conan is still correctly deriving the compiler and version for the host profile, but there are two problems in your case:

• compiler.runtime is not set - this we can fix from cmake-conan as we can assume the CMake defaults based on the build type
• the build profile is incomplete: this can cause problems

I'll get working on a fix for these, thanks for your feedback!
@simonimpey - the behaviour from the Visual Studio IDE may be slightly different, but will be verifying that as well

[simonimpey]

Hi @simonimpey - I've tried to reproduce this on my end, but have been unable to. If I open the project directly from Visual Studio (where the VS IDE invokes CMake, and cmake invokes Conan, and there is no default profile) - it seems to work fine.

conan profile detect should generate a profile like this:

[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.version=193
os=Windows

The compiler.runtime is set to be added in the profile detection logic in the Conan client for the msvc compiler - so I wonder if the issue lies elsewhere.

Are you still able to reproduce this issue? Could you paste the contents of your default profile, or would you be able to remove/rename the default profile from the profiles folder, to force cmake-conan to generate it again? And if you could post the entire output of the log from Visual Studio, that would be great, thanks!

Yes, after the earlier discussion I did exactly that and deleted the 'default' profile and forced conan to regenerate it from a standard Windows Terminal shell. This did indeed set the compiler.runtime setting as required.

I think the original cause of the issue was running conan for the first time and auto detecting the profile from within whatever environment VS uses when processing CMakeLists files. Having said this I feel that the choice of runtime should not be system wide as it should be possible for different projects to specify different runtimes.

[jcar87]

I think the original cause of the issue was running conan for the first time and auto detecting the profile from within whatever environment VS uses when processing CMakeLists files.

In my own tests, Visual Studio was invoking CMake with the "Visual Studio" generator, so the result was the same. Is there a setting to change this to use Ninja instead? If it was using Ninja then it would only fail if the CC/CXX environment variables are used.

Having said this I feel that the choice of runtime should not be system wide as it should be possible for different projects to specify different runtimes.

Indeed, this is going to be addressed in #516

[jhol]

I have encountered the opposite problem, where compiler.runtime=dynamic is set in the default profile, but the GCC-based cross-build tool-chain doesn't support this setting in settings.yml.

In the cross-building case, we don't want to leak anything from the default profile into conan_host_profile, so including the default profile is unwelcome.