CMake Version: 3.27.8 no policy overrides
VS/MSVC installs: VS2019/14.29.30133, VS2022/14.34.31933
I am trying to customize a windows toolchain file to specify the toolset requirements for visual studio when using a Visual Studio 2022 generator, but need a VS 2019 toolset.
set(CMAKE_GENERATOR_TOOLSET "v143,version=14.34.31933" CACHE INTERNAL "The MSVC toolset version")
^^ succeeds finds the expected settings etc. works as expected
set(CMAKE_GENERATOR_TOOLSET "v142" CACHE INTERNAL "The MSVC toolset version")
^^ tells it to use the vs 2019 toolset and finds the 14.29.30133 msvc paths etc. within vs2019 itself. Which sets up the expected $(VC_ReferencesPath_x64) path values etc. and generates a vs2022 solution with the (Visual Studio 2019) brackets on each target. i.e. “Platform Toolset: Visual Studio 2019 (v142)” in the project UI’s.
set(CMAKE_GENERATOR_TOOLSET "v142,version=14.29.30133" CACHE INTERNAL "The MSVC toolset version")
^^ fails with:
Generator
Visual Studio 17 2022
given toolset and version specification
v142,version=14.29.30133
does not seem to be installed at
C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Auxiliary/Build/14.29.30133/Microsoft.VCToolsVersion.14.29.30133.props
I would have expected this to succeed the same as the previous, with the above settings ending up in visual studio, or for both of them to fail with the same reason?
Is there a way to specify that it should search within the vs2019 install paths instead of the vs2022 install paths which it appears to be trying to do? (unsure on this tbh)
I believe CMake projects would want control over whether it picks v142 and treats it as vs2019 in vs2022, or picks v142 and treats it as vs2022 with the vs2019 toolset (i.e. installed as part of vs2022)? i.e. difference between selecting “Visual Studio 2019 (v142)” and “Visual Studio 2022 (v142)” in the UI.
If there is no way to control that currently what is the best way to go about trying to add/extend CMake to handle this? (i.e. the path to go down to result in a PR etc.)
Notes
I haven’t had a chance to test with having the v142 toolset installed as part of my vs2022 install yet i.e. Platform Toolset: Visual Studio 2022 (v142), but I assume this would “work” as expected, i.e. it would use the one installed in vs2022, but then the one with only v142 (i.e. no version) would use the vs2019 install? which seems somewhat confusing/mis-leading. (will hopefully update this once approved to install some older msvc versions in vs2022 etc. for testing this as have now hit a road-block)
Details
Trying to keep this example simple/isolated but is part of a wider cross project setup, I am focusing around ensuring requirements for the specific versions the generators are built with are honoured when building on a machine with possibly multiple versions of MSVC/Visual Studio (vs2017, 2019, 2022). We have our own requirements checks that populate these values that happen at the start of the toolchain based on project specific setting files (to allow us to mostly share cmake setup, and have the code-base handle all the heavy lifting for you, probably akin to some of conans setup). I am mostly wanting to avoid having to write our own windows modules, so it currently still uses the base windows modules after setting these values. For example under ninja we have already setup the environment akin to vscarsall etc. to ensure it finds the correct values and it “just works”, but sadly it can’t be used for all platform tooling (I have tried to keep this example isolated to windows where it reproduces in an easy to test place).
We have found without setting these values the vs generation will still pick the latest version for the VS generator. If there is another way to go about hardening these requirements I would be open to suggestions, but I “think” these values are the “correct” way to control this in modern CMake, and have possible just hit an interesting edge-case.