fix for vcvars for clang with msvc v144 backend

[memsharded]

Changelog: Bugfix: Fix LLVM/Clang enablement of vcvars for latest v14.4 toolset version after VS 17.10 update
Docs: conan-io/docs#3752

Close #16373

[dcoburnMEDITECH]

Any chance this fix can get into 1.x version of conan? We at MEDITECH can't use 2.x as Crashpad is not compatible, and we are running into this issue also.

[memsharded]

Any chance this fix can get into 1.x version of conan? We at MEDITECH can't use 2.x as Crashpad is not compatible, and we are running into this issue also.

That is unfortunate, crashpad might be one of the very few recipes from the +1500 ones in ConanCenter that hasn't been updated yet. There is a PR to update it, but it was red. Have you tried checking it, trying and contributing? This would be the best course of action, Conan 2 is already 16 months since its release, and it is now the recommended version for production.

Also, since the local-recipes-index feature, using dependencies from your own fork of conan-center-index is way easier, so even if the fix is not in ConanCenter yet, you can still run it from your fork.

I'll try to help pushing that crashpad PR.

[memsharded]

An update to Crashpad to make it compatible with Conan 2 is in conan-io/conan-center-index#24320. It is already green, so I hope it doesn't take long to be merged.

Please check it and let me know if there is any issue, the best would be to create a new ticket. Thanks!

[exoosh]

Hi, I sincerely don't have any idea who had the idea map the compiler.runtime_version like this, but this doesn't look good.

The relationship you seem to construe here, simply doesn't exist.

I am talking about these lines and the mentions of a made up v144 in particular.

v140 through v143 describes the "platform toolset" (or PlatformToolset in MSBuild; Microsoft's lingo), indeed. But a v144 does not exist. It will probably exist with the next major VS release, though ... which will be the point at which the above changes will cause further trouble. So while now the value of v144 will chiefly cause trouble when using Clang, the fact that you currently map v144 to version 17 of Visual Studio is probably going to come back to haunt you.

For the native VS2022 toolset it's <PlatformToolset>v143</PlatformToolset> as it always was.

The problem appears to be that because you aren't using MSBuild with clang the compiler.runtime_version is needed and you thought it could be derived from the platform toolset. But both the Visual Studio Installer and existing correlations should quickly tell you that this notion is wrong.

Same VS instance, filtering for the older platform toolset from VS2019:

On a VS2019 instance installed on the same machine:

Of course the older VS2017 platform toolset is also available with VS2019:

As you can see for this v14x the relationship is 1:1, e.g.:

• v140 -> VS2015 (famously also used to have the v140_xp platform toolset which, I think, is now deprecated)
• v141 -> VS2017
• v142 -> VS2019
• v143 -> VS2022
• v144 -> ??? ... some future version if Microsoft doesn't decide to bump it beyond the 140s.

What you seem to be after is $(VCToolsInstallDir) -- on my system %ProgramFiles%\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.40.33807 -- or notably the last path segment (aka $(VCToolsVersion). Which is where the 14.4 comes from, of course. $(VCToolsInstallDir) governs where the C/C++ runtime and headers are located along with the (MSVC) compiler toolchain etc. $(VCToolsetsDir) denotes its parent directory.

Let's look at a sample set of the version numbers in the 2019 and 2022 range and the last path segment that you are after and which you pass to the script as 14.4:

• platform toolset v142 == VS2019
  • 14.29.30133 (VS version 16.11.30)
  • 14.29.30133 (VS version 16.11.32)
  • 14.29.30133 (VS version 16.11.35)
  • 14.29.30133 (VS version 16.11.36)
  • 14.29.30133 (VS version 16.11.37)
• platform toolset v143 == VS2022
  • 14.37.32822 (VS version 17.7.4)
  • 14.37.32822 (VS version 17.7.5)
  • 14.37.32822 (VS version 17.7.6)
  • 14.38.33130 (VS version 17.8.0)
  • 14.38.33130 (VS version 17.8.2)
  • 14.38.33130 (VS version 17.8.5)
  • 14.38.33130 (VS version 17.8.6)
  • 14.39.33519 (VS version 17.9.2)
  • 14.39.33519 (VS version 17.9.4)
  • 14.39.33519 (VS version 17.9.5)
  • 14.39.33519 (VS version 17.9.6)
  • 14.39.33519 (VS version 17.9.7)
  • 14.40.33807 (VS version 17.10.0)
  • 14.40.33807 (VS version 17.10.1)
  • 14.40.33807 (VS version 17.10.2)
  • 14.40.33807 (VS version 17.10.3)

In conclusion, there is no v144 yet. You made it up and unless Microsoft decides to skip some values there, this decision will come back to haunt you as soon as the next major version of VS is getting released. Because then v144 will most likely have indeed a meaning.

If you want to dig deeper, I suggest you have a look into your VS installation directory:

• $(VSInstallDir)MSBuild\Microsoft\VC\v170\Platforms\ARM\PlatformToolsets\v143
• $(VSInstallDir)MSBuild\Microsoft\VC\v170\Platforms\ARM64\PlatformToolsets\v143
• $(VSInstallDir)MSBuild\Microsoft\VC\v170\Platforms\ARM64EC\PlatformToolsets\v143
• $(VSInstallDir)MSBuild\Microsoft\VC\v170\Platforms\Win32\PlatformToolsets\v143
• $(VSInstallDir)MSBuild\Microsoft\VC\v170\Platforms\x64\PlatformToolsets\v143

NB: $(VSInstallDir) == C:\Program Files\Microsoft Visual Studio\2022\Enterprise\ on my system, this should give you an idea (note VS instead of VC in the property name!).

As you can glean from these paths, v170 is the marketing version (major version 17). You may also find a v160 there, which allows the MSBuild inside VS2022 to build with the correct settings for VS2019 (if installed). However, the v143 is a fixture!

[memsharded]

Thanks for the comments @exoosh

I know there is no v144. We have taken that into account for other aspects of the VS 17.10.

But this setting specific for clang was initially mis-named, called v143 that looks like the platform toolset, but in reality it is used internally as the toolset version 14.3, you can see the mapping:

vcvars_ver = {"v140": "14.0",
                          "v141": "14.1",
                          "v142": "14.2",
                          "v143": "14.3",
                          "v144": "14.4"}.get(toolset_version)

in

conan/conan/tools/microsoft/visual.py

Line 135 in 3c72e2a

vcvars_ver = {"v140": "14.0",

The problem is that the previous settings definitions were already part of the public and documented interface of Conan, and they couldn't be changed because it would be very breaking, so we had to add the v144 that doesn't exist as a mis-typed proxy for its real 14.4 toolset version that does exist, and it is the value used under the hood.

[exoosh]

@memsharded fair enough, got it.

PS: One thing you may want to do instead is to extract the relevant values by means of an MSBuild project that runs in a pre-initialized VS build environment. This way you don't have to make these assumptions but instead can rely on well-known property names (some of which I mentioned above).

Here is an example of something I did in my spare time to extract the VS version values from within MSBuild: ClVersionRetrieve.proj.