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?
I don’t think so. What’s the use case?
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.
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
.
Fair enough I’ll investigate further on this issue and see what I can find.
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.
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.