既然v144是msvc的问题，无论msvc还是cmake都不改动，那么可否由使用者主动改动呢？

[augustheart]

联动 #5230 ，根据提示，我找到了判断的地方

local vs_toolset = _get_msvc(package):config("vs_toolset") or config.get("vs_toolset")

可以看到，vs_toolset的值优先从系统获取。
那么，我们可否修改一下，优先以用户提供的为主呢？

local vs_toolset = config.get("vs_toolset") or _get_msvc(package):config("vs_toolset")

这样，在我遇到的情况下，如果不手动设置--vs_toolset，依旧能够和以前一样保持一致，但是在手动设置--vs_tools的时候，可以主动提供14.3覆盖错误的值。

[waruqi]

_get_msvc(package):config("vs_toolset")

这里面 也会优先从 xmake f --vs_toolset= 取。。

xmake/xmake/toolchains/msvc/check.lua

Line 41 in 872ddbd

local vs_toolset = toolchain:config("vs_toolset") or config.get("vs_toolset")

[waruqi]

你调的这个位置，不是首次获取的地方，还得往前调。。

xmake/xmake/toolchains/msvc/check.lua

Line 43 in ecb16eb

local vstudio = find_vstudio({vcvars_ver = vs_toolset, sdkver = vs_sdkver})

这里也会获取 config 里面 vs_toolset 。。然后传入 find_vstudio ，将其传入 vcvallvars.bat 作为参数，让它返回指定 toolset 的 VCToolsVersion

xmake/xmake/modules/detect/sdks/find_vstudio.lua

Line 147 in ecb16eb

file:print("call \"%s\" %s %s > nul", vcvarsall, arch, opt.sdkver and opt.sdkver or "")

也就是说，如果顺利，用户传入的 vs_toolset 会让 vs 返回对应一致的 VCToolsVersion，并不是说用了 VCToolsVersion 就一定是不对的。

你需要跟下整个流程，看看是没传入进去，还是没实际去 find_vstudio，还是 vcallvars.bat 没返回正常

[augustheart]

今天终于摸清楚了问题在哪。
xmake在call vcvarsall.bat的时候，传入了参数-vcvars_ver，这个参数就是外部传入的--vc_toolset。然后，vcvarsall.bat在接受参数的时候，会检测对应的值是否存在，如果不存在，则不会接受这个值。这就是为什么我传入14.5的时候不会被接受的原因。
然后，原本应该是正确的14.3也不被接受，那是因为它不是14.3，而是14.29。虽然我曾经瞄到过这个目录，但是没多往这方面想，一直以为vc_toolset输入的应该是在vs中输入的平台工具集 或是cmake 所接受的那个143，而我直到看到config:get部分的代码，也还是以为输入的是14.3。
修正：由于我装了多个版本的cl，然后我发现14.29最后在cmake对应的是142，上面看错了
然后我测试了一下，14.16对应141，14.29对应142，最后，确实是有一个14.40.33807的目录，但是14.40不正确，这又回到了issue的起点了。不过总算搞清楚这一圈到底怎么回事了。

[waruqi]

那就是还是生效的咯，只是传参值没完全对上么

[augustheart]

那就是还是生效的咯，只是传参值没完全对上么

对的，最后发现就是这么回事。
然后，这个结果到会出现一个割裂的问题，同样是传给--vc_toolset的值，toolchian:get的和config:get的是不同的。
昨天后来才看到xmake出新版，还没试用新版

[waruqi]

config.get 是用户传入的值，toolchain.get 获取的是真实的精准版本。这个目前没办法，你只能尽可能传入精准值，因为要依赖 vcallvars.bat