CMake caching pain with MSVC update

[huoyaoyuan]

49906 introduces a caching mechanism for cmake intermediate files. This works fine in daily work, but every time when there's an update to VS and MSVC, the full path of MSVC (version number included) will change, and an error will be reported by ninja:

    The CMAKE_CXX_COMPILER:

      C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.34.31933/bin/Hostx64/x64/cl.exe

    is not a full path to an existing compiler tool.

Surprised that nobody claimed for this.

Ideally, the script should detect for MSVC update, and invoke cmake proactively when there's an update. If this can't be achieved easily, there should be some documentation about which file to delete in order to regenerate the cache.

BTW, building coreclr with VS open folder experience refreshes the cache in windows.\<arch>.\<configuration>, but not linux.\<arch>.\<configuration> which is used for LinuxDac.

[ghost]

Tagging subscribers to this area: @hoyosjs See info in area-owners.md if you want to be subscribed.

Issue Details

---

#49906 introduces a caching mechanism for cmake intermediate files. This works fine in daily work, but every time when there's an update to VS and MSVC, the full path of MSVC (version number included) will change, and an error will be reported by ninja: ``` The CMAKE_CXX_COMPILER: C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.34.31933/bin/Hostx64/x64/cl.exe is not a full path to an existing compiler tool. ``` Surprised that nobody claimed for this. Ideally, the script should detect for MSVC update, and invoke cmake proactively when there's an update. If this can't be achieved easily, there should be some documentation about which file to delete in order to regenerate the cache. BTW, building coreclr with VS open folder experience refreshes the cache in windows.., but not linux.. which is used for LinuxDac.

Author:	huoyaoyuan
Assignees:	-
Labels:	`area-Infrastructure-coreclr`, `untriaged`
Milestone:	-

[hoyosjs]

@jkoritzinsky should we try to serialize more than just the commandline? Something like a "determinism json" with sorted keys?

[jkoritzinsky]

I just tested this locally by removing the cache in #49906 and I still hit the same failure. This is an issue with how CMake resolves and caching compiler paths. CMake caches the paths in the CMakeCache.txt file (CMake's cache, not ours), which it then loads from even when reconfiguring. It does not try to rediscover the compiler location when reconfiguring. It only does so on the initial configure. The only thing we could do here is check for the existence of the compiler specified in CMake's cache and wipe the cache file ourselves to force compiler rediscovery.

This does not affect the Visual Studio generators as they do not use these CMake paths since MSBuild just uses the MSVC that is in VS. this affects Ninja as Ninja uses a similar compiler discovery mechanism as Make (where you give it a path) so CMake needs to track the path of the compiler.

Honestly, the right thing to delete when this happens is the entire artifacts/obj/coreclr directory as none of the artifacts should be reused as static linking requires a matching toolset version, and a failure in this manner means that your toolset has been updated.