Feature request: list platform toolset and VC tools versions available
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 991
- Forks
- 105
- PR merge metrics
- No merged PRs in 30d
Description
With the introduction of VS 17.1x earlier this year, and the subsequent bump of VCToolsVersion to 14.4x.xxxxx, it's now necessary for build tools to include a non-forward compatible hack to check for the platform toolset v143 since it's otherwise identified as v144 (see https://devblogs.microsoft.com/cppblog/msvc-toolset-minor-version-number-14-40-in-vs-2022-v17-10/).
e.g.:
- CMake: https://gitlab.kitware.com/cmake/cmake/-/issues/26015
- XMake: https://github.com/xmake-io/xmake/pull/5176
- OpenCV: https://github.com/opencv/opencv/pull/25638
It'd be great if either vswhere could implement a forward-compatible non-hack to determine the platform toolset version(s) available, or if that's not possible, at least centralize the hacks so build tools can avoid each have their own implementations.
There is an implied solution in vcvars.bat, where it will read the value of VCToolsVersion from %VCINSTALLDIR%Auxiliary\Build\Microsoft.VCToolsVersion.v143.default.txt if it exists, and fall back to the value in %VCINSTALLDIR%Auxiliary\Build\Microsoft.VCToolsVersion.default.txt ("latest" according to the comments).
So I believe the correct solution would be to search %VCINSTALLDIR%Auxiliary\Build\Microsoft.VCToolsVersion.*.default.txt, extract the platform toolset version from the filename, and read the VCToolsVersion from the file. Including the "latest" tools version from Microsoft.VCToolsVersion.default.txt would be nice too.
This doesn't work however when there are multiple SxS versions of the same platform toolset, as they will be in Auxilliary\Build\XX.YY.MM.mm\Microsoft.VCToolsVersion.XX.YY.MM.mm.txt with no way to map XX.YY to a platform toolset version since the XX.YY suffers from the same v144 issue we're trying to solve.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by examining vswhere's existing toolset discovery entry points and compare them with the vcvars.bat lookup described in the issue. Check how Microsoft.VCToolsVersion.*.default.txt and SxS files could be mapped, and define completion around reliably reporting available platform toolset and latest tool versions without duplicating build-tool-specific hacks.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- build-system, devtools
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100