CMake 3.21 | Global NO_CACHE?

Usage
1

As of CMake 3.21 there is a NO_CACHE for find_* commands.

The find_file(), find_path(), find_program(), and find_library() commands gained the option NO_CACHE to store find result in normal variable.

Is there a way to set this NO_CACHE variable globally for the project?

2

I don’t think so. What’s the use case?

3

From @craig.scott’s book:

Incremental builds + find_* + cache variables cause potential build problems. Chapter 24 finding things.

Since I am the top level project I’d like to globally change this behavior. Instead of manually changing each find_* call. And keep track of any potential new find_* calls.

4

I wonder how much of that is because of oddities between cache and local variable interactions (see this issue) rather than find_* calls specifically. Before that, let’s investigate the behavior with CMP0077, CMP0102, CMP0125, and CMP0126 all set to NEW before declaring this as necessary.

On the other hand, find_ command arguments do have global controls otherwise, so maybe it makes sense anyways. But I’d still like to see some investigation into:

  • behavior after all of the cache/scope interaction fix policies
  • performance hit for find_-heavy projects
  • the potential for skew when find modules are not synchronized
    • the case that I can think of is FindBoost (or another similarly complicated one, like FindMPI or FindPython) in CMake versus a patched one where one supports a version/library that the other doesn’t and finds a different version because of $reasons.
5

Fair enough I’ll investigate further on this issue and see what I can find.

6

I don’t think this will happen because it is not acceptable to change implicitly behavior of CMake commands: find_* commands, as described in documentation, create, by default, a cache variable. So developers and users rely on this standard behavior and, consequently, cannot be changed.

7

The find_ commands already have external controls for things such as find roots and such (the CMAKE_FIND_ variables). Sure, they’re useful for toolchains mostly, but that’s why I’m interested in a use case for this variable before we actually add it.