Feature request: list platform toolset and VC tools versions available #321
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: Fix VS toolset v144 xmake-io/xmake#5176
- OpenCV: Support VS 2022 17.1x.y in OpenCVDetectCXXCompiler.cmake opencv/opencv#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.