Rediscover toolchain as needed

[MathiasMagnus]

Fixes #10

I got to the bottom of the issue and prepared a fix that suits my use case and likely that of others.

The problem

Apple decided to put some important/critical system components into encrypted, read-only disk images which are mounted on demand. The Metal toolchain is one such component. It is not mounted until either Xcode is launched or some xcrun et al. command is run.

The reason why after reboots the first configuration fails, is that the mount location has a random hash component, but the full path to the Metal compiler is baked into <binary_dir>/CMakeFiles/<cmake_ver>/CMakeMetalCompiler.cmake. Upon first post-reboot configuration, when project(A LANGUAGES Metal) is called, the module-supplied CMakeDetermineMetalCompiler.cmake isn't consulted because the cached results are found on disk. The cached path is stale and some check fails resulting in a configuration time error and the deletion of the stale cache file. Thus during the second post-reboot configuration CMakeDetermineMetalCompiler.cmake is consulted again, which in turn calls xcrun --find metal mounting the toolchain again.

Solutions

Detecting the staleness of the cached compiler path in theory could be done elegantly from MetalShaderSupport.cmake, however the variable CMAKE_PLATFORM_INFO_DIR used to find the location of the toolchain cache file isn't defined when non-CMake machinery runs. Otherwise detecting the staleness there and deleting the file before project() is reached for a clean toolchain detection would be nice. The workaround is the reiterate some of the detection logic in the cache file itself. If the compiler "disappeared" and if it finds a compiler of the same version as previously, then it overwrites the cached variable.