[bug] vcvars not called when using Visual Studio 17.10 + clang

[sykhro]

Describe the bug

Windows 11
Visual Studio 17.10.1
Conan version 2.3.2

vcvars is not sourced correctly resulting in some libraries failing to build

How to reproduce it

I have a profile as follows:

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

compiler=clang
compiler.version=17
compiler.runtime=dynamic
compiler.runtime_type=Debug
compiler.runtime_version=v143
 
[conf]
tools.cmake.cmaketoolchain:generator=Ninja Multi-Config

all recipes show the following:

conanvcvars.bat: Activating environment Visual Studio 17 - amd64 - winsdk_version=None - vcvars_ver=14.3
[ERROR:vcvars.bat] Toolset directory for version '14.3' was not found.
[ERROR:VsDevCmd.bat] *** VsDevCmd.bat encountered errors. Environment may be incomplete and/or incorrect. ***
[ERROR:VsDevCmd.bat] In an uninitialized command prompt, please 'set VSCMD_DEBUG=[value]' and then re-run
[ERROR:VsDevCmd.bat] vsdevcmd.bat [args] for additional details.
[ERROR:VsDevCmd.bat] Where [value] is:
[ERROR:VsDevCmd.bat]    1 : basic debug logging
[ERROR:VsDevCmd.bat]    2 : detailed debug logging
[ERROR:VsDevCmd.bat]    3 : trace level logging. Redirection of output to a file when using this level is recommended.   
[ERROR:VsDevCmd.bat] Example: set VSCMD_DEBUG=3
[ERROR:VsDevCmd.bat]          vsdevcmd.bat > vsdevcmd.trace.txt 2>&1

and some decide to die right after (e.g. libjpeg-turbo)
I can see in the code that v143 is mapped to vcvars_ver=14.3:

conan/conan/tools/microsoft/visual.py

Lines 133 to 136 in 5abec94

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

However, when using 17.10, the 14.3 tools are wiped by the VS installer. In light of this bug and work I've been doing lately around VS, I express desire for:

• a way to specify the vcvars_version
• a way to pass a different setup script entirely (ties back into [feature] More customization options for Platform and PlatformToolset in MSBuildToolchain #16276)

[sykhro]

(ties back into #16276)

Note: at the moment I'm not using MSBuildToolchain. I'm actually trying to build a CMake toolchain for these platforms with Ninja; the CMake experience with the VS generator is close to awful at least for this usecase

[memsharded]

Thanks for the report @sykhro

At the moment, at least with my LLVM/Clang 16, it seems it is not compatible with the new v14.4 toolset version, I am getting compile errors like:

#define _EMIT_STL_ERROR(NUMBER, MESSAGE) static_assert(false, "error " #NUMBER ": " MESSAGE)

(after fixing the Conan internals to compute the v14.4 for vcvars for clang.

I'll try using latest clang.

Update: It works fine with latest llvm/clang 18.1.6

[sykhro]

Thanks for the report @sykhro

At the moment, at least with my LLVM/Clang 16, it seems it is not compatible with the new v14.4 toolset version, I am getting compile errors like:

#define _EMIT_STL_ERROR(NUMBER, MESSAGE) static_assert(false, "error " #NUMBER ": " MESSAGE)

(after fixing the Conan internals to compute the v14.4 for vcvars for clang.

I'll try using latest clang.

Update: It works fine with latest llvm/clang 18.1.6

That's expected, the MS STL has been requiring clang >= 17 since at least VS 17.7
https://github.com/microsoft/STL/blob/872f4768724bf77d95d6eb2f4c637dd66e2099a1/stl/inc/yvals_core.h#L894

[memsharded]

I am proposing #16374 to fix this (irrespective of the other ticket, trying to make more flexible the customization is a good idea, but this needs to work without customization).

In short:

• Augment the clang settings to include compiler.runtime_version=v144. The v144 is actually the toolset version v14.4, not the toolset platform v144, that doesn0t exist, but unfortunately, the runtime_version subsetting in settings.yml, didn't explicitly define the dot that corresponds to the toolset version and does the conversion internally.
• Use that in the VCVars class
• Make sure that the new tools.microsoft:msvc_update is also taken into account in this place of VCVars usage.

I have been testing it locally and seems to work, feedback very welcome.

[sykhro]

I am proposing #16374 to fix this (irrespective of the other ticket, trying to make more flexible the customization is a good idea, but this needs to work without customization).

In short:

• Augment the clang settings to include compiler.runtime_version=v144. The v144 is actually the toolset version v14.4, not the toolset platform v144, that doesn0t exist, but unfortunately, the runtime_version subsetting in settings.yml, didn't explicitly define the dot that corresponds to the toolset version and does the conversion internally.
• Use that in the VCVars class
• Make sure that the new tools.microsoft:msvc_update is also taken into account in this place of VCVars usage.

I have been testing it locally and seems to work, feedback very welcome.

It seems fine to me. I wonder how this could be handled when platform v144 is released, considering the toolset version is probably going to be 14.5 or something like that (blog post)

[sykhro]

it shouldn't be a problem until 2026 is their release cycle/timeline is to be trusted...

[sykhro]

regardless of this, I think that more customisation points would be good - I find it strange that I can edit settings.yml however I please but have little control over how vcvars are sourced

[memsharded]

regardless of this, I think that more customisation points would be good - I find it strange that I can edit settings.yml however I please but have little control over how vcvars are sourced

Yes, I am not opposed to customization points, it is just we haven't been able to prioritize it yet, while this kind of bug is a much higher priority.

[memsharded]

Fixed in #16374 for next Conan 2.4

[sykhro]

Thanks!