CMake configure step vs CMakeCache.txt: when do cached check results invalidate?

Integration boundary

The CMake configure step runs check modules such as check_cxx_source_compiles and stores their boolean outcomes in CMakeCache.txt. On subsequent reconfigures, CMake skips a check if its cache variable already exists, which means the result can persist even when the compiler, CMAKE_REQUIRED_FLAGS, or the toolchain file has changed.

Unresolved behavior

There is no built-in dependency tracking that ties a cached check result to the exact compiler invocation or flag set used when the check originally ran. Switching compilers, adjusting required flags, or editing a cross-compilation toolchain does not automatically invalidate the corresponding cache entries. Projects must decide manually when to delete CMakeCache.txt or individual entries to force re-evaluation.

Goal

Understand the precise conditions under which a cached check result remains valid versus when it becomes stale, so that a build system can reliably detect toolchain or flag changes without requiring a full cache wipe.

• Which cache variables or internal markers does CMake consult to decide whether a try_compile or check_* result should be reused?
• Does the newer try_compile signature with SOURCE_FROM_CONTENT and CMAKE_TRY_COMPILE_TARGET_TYPE alter the invalidation semantics?
• Are there any documented or undocumented mechanisms (e.g., cache variable prefixes, internal timestamps) that a project can hook into for automatic invalidation?