[feature] CMakePresets support for msvc toolset version #13136
Comments
|
thanks for your detailed report. Quick question, isn't Conan generating the right toolset inside the {% if generator_platform %}
set(CMAKE_GENERATOR_PLATFORM "{{ generator_platform }}" CACHE STRING "" FORCE)
{% endif %}
{% if toolset %}
set(CMAKE_GENERATOR_TOOLSET "{{ toolset }}" CACHE STRING "" FORCE)
{% endif %}The reason why things are by default if possible in the toolchain file is because conan needs to be compatible down to CMake 3.15, so no presets. The more things we put in the presets, the more complicated is for developers with CMake < 3.20 to issue a command line that will work for them. |
|
Hrmm. Doesn't look like it. If I run the following: $ conan new hello/0.1 --template cmake_libAnd then install that project: $ conan install conanfile.py -pr:b x86_64-windows-msvc143 -pr:h x86-windows-msvc143$ conan profile show x86-windows-msvc143$ conan profile show x86_64-windows-msvc143Conan generates the following: CMakePresets.json{
"version": 3,
"vendor": {
"conan": {}
},
"cmakeMinimumRequired": {
"major": 3,
"minor": 15,
"patch": 0
},
"configurePresets": [
{
"name": "relwithdebinfo",
"displayName": "'relwithdebinfo' config",
"description": "'relwithdebinfo' configure using 'Ninja' generator",
"generator": "Ninja",
"cacheVariables": {
"CMAKE_POLICY_DEFAULT_CMP0091": "NEW",
"CMAKE_BUILD_TYPE": "RelWithDebInfo"
},
"architecture": {
"value": "x86",
"strategy": "external"
},
"toolchainFile": "C:\\projects\\build\\conan\\build\\RelWithDebInfo\\generators\\conan_toolchain.cmake",
"binaryDir": "C:\\projects\\build\\conan\\build\\RelWithDebInfo"
}
],
"buildPresets": [
{
"name": "relwithdebinfo",
"configurePreset": "relwithdebinfo"
}
],
"testPresets": [
{
"name": "relwithdebinfo",
"configurePreset": "relwithdebinfo"
}
]
}CMakeUserPresets.json{
"version": 4,
"vendor": {
"conan": {}
},
"include": [
"C:\\projects\\build\\conan\\build\\RelWithDebInfo\\generators\\CMakePresets.json"
]
}conan_toolchain.cmake# Conan automatically generated toolchain file
# DO NOT EDIT MANUALLY, it will be overwritten
# Avoid including toolchain file several times (bad if appending to variables like
# CMAKE_CXX_FLAGS. See https://github.com/android/ndk/issues/323
include_guard()
message(STATUS "Using Conan toolchain: ${CMAKE_CURRENT_LIST_FILE}")
if(${CMAKE_VERSION} VERSION_LESS "3.15")
message(FATAL_ERROR "The 'CMakeToolchain' generator only works with CMake >= 3.15")
endif()
# Definition of VS runtime, defined from build_type, compiler.runtime, compiler.runtime_type
cmake_policy(GET CMP0091 POLICY_CMP0091)
if(NOT "${POLICY_CMP0091}" STREQUAL NEW)
message(FATAL_ERROR "The CMake policy CMP0091 must be NEW, but is '${POLICY_CMP0091}'")
endif()
set(CMAKE_MSVC_RUNTIME_LIBRARY "$<$<CONFIG:RelWithDebInfo>:MultiThreadedDLL>")
# Extra c, cxx, linkflags and defines
if(DEFINED CONAN_CXX_FLAGS)
string(APPEND CMAKE_CXX_FLAGS_INIT " ${CONAN_CXX_FLAGS}")
endif()
if(DEFINED CONAN_C_FLAGS)
string(APPEND CMAKE_C_FLAGS_INIT " ${CONAN_C_FLAGS}")
endif()
if(DEFINED CONAN_SHARED_LINKER_FLAGS)
string(APPEND CMAKE_SHARED_LINKER_FLAGS_INIT " ${CONAN_SHARED_LINKER_FLAGS}")
endif()
if(DEFINED CONAN_EXE_LINKER_FLAGS)
string(APPEND CMAKE_EXE_LINKER_FLAGS_INIT " ${CONAN_EXE_LINKER_FLAGS}")
endif()
get_property( _CMAKE_IN_TRY_COMPILE GLOBAL PROPERTY IN_TRY_COMPILE )
if(_CMAKE_IN_TRY_COMPILE)
message(STATUS "Running toolchain IN_TRY_COMPILE")
return()
endif()
set(CMAKE_FIND_PACKAGE_PREFER_CONFIG ON)
# Definition of CMAKE_MODULE_PATH
# Explicitly defined "buildirs" of "build" context dependencies
# the generators folder (where conan generates files, like this toolchain)
list(PREPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_LIST_DIR})
# Definition of CMAKE_PREFIX_PATH, CMAKE_XXXXX_PATH
# The Conan local "generators" folder, where this toolchain is saved.
list(PREPEND CMAKE_PREFIX_PATH ${CMAKE_CURRENT_LIST_DIR} )
if(NOT DEFINED CMAKE_FIND_ROOT_PATH_MODE_PACKAGE OR CMAKE_FIND_ROOT_PATH_MODE_PACKAGE STREQUAL "ONLY")
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE "BOTH")
endif()
if(NOT DEFINED CMAKE_FIND_ROOT_PATH_MODE_PROGRAM OR CMAKE_FIND_ROOT_PATH_MODE_PROGRAM STREQUAL "ONLY")
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM "BOTH")
endif()
if(NOT DEFINED CMAKE_FIND_ROOT_PATH_MODE_LIBRARY OR CMAKE_FIND_ROOT_PATH_MODE_LIBRARY STREQUAL "ONLY")
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY "BOTH")
endif()
if(NOT DEFINED CMAKE_FIND_ROOT_PATH_MODE_INCLUDE OR CMAKE_FIND_ROOT_PATH_MODE_INCLUDE STREQUAL "ONLY")
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE "BOTH")
endif()
if (DEFINED ENV{PKG_CONFIG_PATH})
set(ENV{PKG_CONFIG_PATH} "C:/projects/build/conan/build/RelWithDebInfo/generators;$ENV{PKG_CONFIG_PATH}")
else()
set(ENV{PKG_CONFIG_PATH} "C:/projects/build/conan/build/RelWithDebInfo/generators;")
endif()
message(STATUS "Conan toolchain: Setting BUILD_SHARED_LIBS = OFF")
set(BUILD_SHARED_LIBS OFF CACHE BOOL "Build shared libraries")
# Variables
# Variables per configuration
# Preprocessor definitions
# Preprocessor definitions per configuration
Unfortunately, I'm not seeing |
|
If I try the same thing with the $ conan install conanfile.py -pr:b x86_64-windows-msvc-143 -pr:h x86-windows-msvc-143$ conan profile show x86-windows-msvc-143$ conan profile show x86_64-windows-msvc-143Conan generates the following: CmakePresets.jsonCMakeUserPresets.jsonconan_toolchain.cmakeIf I then add tools.cmake.cmaketoolchain:generator=Ninja
+tools.cmake.cmaketoolchain:toolset_arch=x64Then I see toolset partially added to the generated CMakePresets.json: "generator": "Ninja",
"cacheVariables": {
"CMAKE_POLICY_DEFAULT_CMP0091": "NEW",
"CMAKE_BUILD_TYPE": "RelWithDebInfo"
},
+"toolset": {
+ "value": "host=x64",
+ "strategy": "external"
+},
"architecture": {
"value": "x86",
"strategy": "external"
},But, in order to get VSCode (and hopefully Qt Creator soon) to detect / pick the right toolset, it needs to be: "toolset": {
- "value": "host=x64",
+ "value": "v193,host=x64",
"strategy": "external"
},And like the "Visual Studio" compiler, I'm not seeing |
Completely understandable. I appreciate your commitment to maintaining support/stability for folks on older versions of CMake. I guess I was under the impression that when That's certainly what the CMake 3.20 cmake-presets doc seems to suggest:
Same for the MSDN doc according to Select your target and host architecture when building with the Visual C++ toolset:
As best I can tell, these Conan just needs to prefix the conan/conan/tools/cmake/presets.py Line 70 in aef2eea Really bad psuedo code: +toolset_version = msvc_version_to_toolset_version(conanfile.settings.get_safe("compiler.version"))
+toolset_value = toolset_version
+if toolset_arch:
+ toolset_value = toolset_value + "," + toolset_arch
ret["toolset"] = {
- "value": toolset_arch,
+ "value": toolset_value
"strategy": "external"
} |
|
Anyways, I can always work around the issue if needed. I think it'd be consistent and an improvement with what Conan is already doing, and improved CMakePresets support seems like the direction a lot of IDEs are going, but I totally understand the compatibility concerns. If the request is not in alignment with where Conan is going at present, feel free to close the issue :) Thanks again for considering the request. Conan is a tremendous product and you, your team, and this community do a tremendous job. Keep up the good work! |
|
CMAKE_GENERATOR_TOOLSET only affects the Visual Studio generators (well, and also Xcode and Green Hills MULTI, for non-MSVC usage). And it doesn't set the environment directly even then - it just puts the toolset into the .vcxproj files, leaving the ultimate resolution for MSBuild. It doesn't have any effect at all when you are using Ninja/Make/etc - those rely on you having already called vcvarsall. conan handle that for itself, by putting the vcvars call into conanbuild.bat (and thus into anything launched by the conanfile.py's These |
|
@thorntonryan, does this workaround still work for you with Conan 2.0? I am getting "No CMAKE_CXX_COMPILER could be found." which means that the VSCode does not load |
|
@mpusz , Using Conan 1.58 and a project using ```diff
{
"version": 4,
"vendor": {
"conan": {}
},
"include": [
"C:\\path\\to\\build\\Debug\\generators\\CMakePresets.json",
"C:\\path\\to\\buid\\RelWithDebInfo\\generators\\CMakePresets.json"
- ]
+ ],
+ "configurePresets": [
+ {
+ "name": "Debug",
+ "displayName": "Debug",
+ "inherits": "debug",
+ "toolset": {
+ "value": "v143,host=x64",
+ "strategy": "external"
+ },
+ "cacheVariables": {
+ "CMAKE_CXX_COMPILER": "cl.exe",
+ "CMAKE_MAKE_PROGRAM": "ninja.exe"
+ }
+ },
+ {
+ "name": "RelWithDebInfo",
+ "displayName": "RelWithDebInfo",
+ "inherits": "relwithdebinfo",
+ "toolset": {
+ "value": "v143,host=x64",
+ "strategy": "external"
+ },
+ "cacheVariables": {
+ "CMAKE_CXX_COMPILER": "cl.exe",
+ "CMAKE_MAKE_PROGRAM": "ninja.exe"
+ }
+ }
+ ],
+ "buildPresets": [
+ {
+ "name": "Debug",
+ "displayName": "Debug",
+ "configurePreset": "Debug",
+ "configuration": "Debug"
+ },
+ {
+ "name": "RelWithDebInfo",
+ "displayName": "RelWithDebInfo",
+ "configurePreset": "RelWithDebInfo",
+ "configuration": "RelWithDebInfo"
+ }
+ ]
}Honestly not sure why these need to be defined. I thought I've called But at least it finds the right Maybe try that? |
|
Thanks! By adding the following: {
"version": 3,
"vendor": {
"conan": {}
},
"cmakeMinimumRequired": {
"major": 3,
"minor": 15,
"patch": 0
},
"configurePresets": [
{
"name": "conan-msvc-193",
"displayName": "'conan-msvc-193' config",
"description": "'conan-msvc-193' configure using 'Ninja Multi-Config' generator",
"generator": "Ninja Multi-Config",
"cacheVariables": {
"CMAKE_POLICY_DEFAULT_CMP0091": "NEW",
+ "CMAKE_CXX_COMPILER": "cl.exe"
},
"architecture": {
"value": "x64",
"strategy": "external"
},
+ "toolset": {
+ "value": "v143,host=x64",
+ "strategy": "external"
+ },
"toolchainFile": "D:\\repos\\units\\build\\msvc-193\\generators\\conan_toolchain.cmake",
"binaryDir": "D:\\repos\\units\\build\\msvc-193"
}
],
"buildPresets": [
{
"name": "conan-msvc-193-release",
"configurePreset": "conan-msvc-193",
"configuration": "Release"
}
],
"testPresets": [
{
"name": "conan-msvc-193-release",
"configurePreset": "conan-msvc-193",
"configuration": "Release"
}
]
}I was able to make MSVC 193 work somehow. The only problem compared to running from VS Dev prompt is that I get the following warning: However, when I tried to do the same for MSVC 192 installed under VS2022 it didn't work. I also tried with |
|
There is already Except this is not correctly prefixed with |
|
Hi all, I am checking this, but need some guidance, it would be necessary to update the reproduction, it seems that latest Conan 2.0.17 is adding Steps:
Can anyone please provide with detailed updated repro? Thanks! |
|
Without I expect you got the warning
Did you have the x86 host toolchain installed? Just guessing, but Microsoft may finally have switched to x64 as the default (and only) installed host toolset for v143. |
But even if I add it manually to my presets, still same error. (I will clarify in my above steps). Not really a x86 toolchain issue, it seems that even with the |
|
When you do that, what messages do you get in the "Output" panel? |
|
|
No warnings prefixed with The invocation of vswhere is silent in that output |
|
Yes, that is right, adding both Seems to make it work. The output was sometimes confusing, because it runs automatically before adding it, so it is not clear if it is running with your latest changes or running the previous state. Maybe making to add cl.exe to Presets (at the moment it only adds it to |
|
By the way, the way to define the x64 toolset is: and that will make automatically |
Minor correction, but this requirement is a subtle wrinkle of |
|
Yeah, my understanding is that the integration of cmake-tools for VSCode checks the CMAKE_XX_COMPILER to decide to call vcvars automatically. |
|
One other thing that seems missing here is a way to have the toolset be something like So maybe |
|
Hmm, actually this seems to be partially in place already: GenericSystemBlock.get_toolset already has code to use settings.compiler.version and settings.compiler.update such that compiler.version=193 and compiler.update=7 would result in toolset=...,version=14.37. Which I think is good enough - Visual Studio doesn't support side-by-side patch versions, just side-by-side minors, so there's little reason to what to specify a 3- or 4-digit version anyway. And if you care, you probably care enough that putting it in settings (and thus getting distinct package_id) is appropriate. But conan.tools.microsoft.visual._vcvars_vers does not seem to have similar code to consider settings.compiler.update, so it will only do 14.1, 14.2, or 14.3, but never distinguish |
|
Split off the VCvars issue as #15522, since that's not actually about CMakePresets |
|
#15522 has been merged it will be in Conan 2.3. I was having another look, this is the current state:
Can anyone please confirm this? The only missing gap would be the |
What is your suggestion?
Suggestion
Would it be possible for the Conan generated CMakePresets.json to include
msvc.toolsetversion details (i.e.v143,v142, etc.) when populating thetoolset.valuefield?This would allow IDEs to know which
vcvarsall.batenvironment to use when building the project.Expected Behavior
For example, when cross-compiling with VS2022 x64 to x86, I'd expect to see the conan generated CMakePresets.json look something like:
"generator": "Ninja", "cacheVariables": { "CMAKE_POLICY_DEFAULT_CMP0091": "NEW", "CMAKE_BUILD_TYPE": "RelWithDebInfo" }, "architecture": { "value": "x86", "strategy": "external" }, +"toolset": { + "value": "v143,host=x64", + "strategy": "external" +}, "toolchainFile": "C:\\projects\\build\\foo\\RelWithDebInfo\\generators\\conan_toolchain.cmake", "binaryDir": "C:\\projects\\build\\foo\\RelWithDebInfoI can use
tools.cmake.cmaketoolchain:toolset_arch=x64to add the "host=x64" portion, but I don't have anyway to getv143added.VSCode recognizes this
toolset/architecturecombination and correctly chooses VS2022 and callsvcvarsall.bat amd64_x86prior to calling CMake.Current Behavior
Conan doesn't include
toolsetdetails in the generated CMakePresets.json file, so in order to get IDEs like VSCode to find the right environment, we need to adjust CMakePresets.json (as described above) or worse adjust the CMakeUserPresets.json file as follows:{ "version": 4, "vendor": { "conan": {} }, "include": [ "C:\\path\\to\\conan\\CMakePresets.json" - ] + ], + "configurePresets": [ + { + "name": "RelWithDebInfo", + "displayName": "RelWithDebInfo", + "inherits": "relwithdebinfo", + "toolset": { + "value": "v143,host=x64", + "strategy": "external" + } + ], + "buildPresets": [ + { + "name": "RelWithDebInfo", + "displayName": "RelWithDebInfo", + "configurePreset": "RelWithDebInfo", + "configuration": "RelWithDebInfo" + } + ] }Conan already knows which vcvarsall to call, and and ensures the correct one gets called in the generated
conanvcvars.bat.Conan also appears to know about
msvc.toolsetversion information:conan/conans/client/conf/__init__.py
Line 117 in e33b55a
At least for the legacy toolsets
And seems to know about the mapping:
conan/conan/tools/microsoft/visual.py
Lines 53 to 60 in e0a8ee0
It seems like Conan could should be able to use the
msvc.toolsetinformation from the build profile and populate the version field correctly.Context
Follow up to #11623
Some IDEs are capable of targeting multiple toolsets (e.g. VS2015, VS2019, VS2022), and
toolset.valueis the way for the IDE to know whichvcvarsall.batto load and use internally while compiling.microsoft/vscode-cmake-tools#2524
QTCREATOR-BUG 28693
Thanks for your support!
Have you read the CONTRIBUTING guide?
The text was updated successfully, but these errors were encountered: