CI(Windows): pin msvc-2022 toolset to v143 / vcvars_ver=14.4#6186
Merged
Conversation
Previously only the msvc-2019 leg was pinned (vcvars_ver=14.2 at the VsDevCmd sites, PlatformToolset=v142 for MSBuild) while msvc-2022 fell through to whatever toolset the VS install defaults to. Pin msvc-2022 explicitly so a newer MSVC shipped inside the same VS install can't be picked up implicitly on an AMI bump. 14.4 prefix-matches the currently installed 14.44 toolset (v143); PlatformToolset=v143 is the stable MSBuild name.
… vars Move the toolset pin out of the inline call-site fromJSON expressions into two job-level env vars defined the same way as CUDA_VERSION, so the per-compiler values live in one place instead of being repeated at each VsDevCmd / MSBuild call site.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Pin the MSVC toolset explicitly on the msvc-2022 Windows leg so a newer compiler shipped inside the same Visual Studio install can't be picked up implicitly on an AMI bump. The msvc-2019 leg was already pinned (
14.2/v142); this brings msvc-2022 to14.4/v143.The per-compiler values are derived into two job-level env vars using the same
fromJSON([...])[cxx_compiler == 'msvc-2019']idiom already used forCUDA_VERSION, so they live in one place:VCVARS_VER→-vcvars_verat all 6VsDevCmd.batcall sites (C/C# bindings, CMake build, Python bindings, C++/C examples).PLATFORM_TOOLSET→;PlatformToolset=on the MSBuild leg.Note on
14.4(not14.3):-vcvars_verprefix-matches an installed MSVC toolset directory, and the v143 line moved into the 14.4x numbering. The runner currently installs14.44, which14.4resolves to.PlatformToolset=v143is the stable MSBuild name and is unaffected.Test plan
Verified on the PR (minimal) Windows config — log lines confirm the resolved toolset per leg:
-vcvars_ver=14.4resolves toMSVC 19.44.35227.0(VC\Tools\MSVC\14.44.35207);PlatformToolset=v143against14.44.35207-vcvars_ver=14.2resolves toMSVC 19.29.30159.0(14.29.30133)Full per-config matrix (Debug+Release × CMake+MSBuild, both compilers) runs on
masterafter merge.