# CMake 3.21 | Global NO\_CACHE?
**URL:** https://discourse.cmake.org/t/cmake-3-21-global-no-cache/3664
**Category:** Usage
**Created:** [June 30, 2021, 5:24pm UTC](https://discourse.cmake.org/t/cmake-3-21-global-no-cache/3664 "2021-06-30T17:24:47Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@buildSystemPerson](https://discourse.cmake.org/u/buildSystemPerson)
#### Post date: [June 30, 2021, 5:24pm UTC](https://discourse.cmake.org/t/cmake-3-21-global-no-cache/3664/1 "2021-06-30T17:24:47Z")
As of CMake 3.21 there is a NO\_CACHE for find\_\* commands.
```auto
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?
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [June 30, 2021, 5:34pm UTC](https://discourse.cmake.org/t/cmake-3-21-global-no-cache/3664/2 "2021-06-30T17:34:54Z")
I don’t think so. What’s the use case?
---
### Author:  [@buildSystemPerson](https://discourse.cmake.org/u/buildSystemPerson)
#### Post date: [June 30, 2021, 5:53pm UTC](https://discourse.cmake.org/t/cmake-3-21-global-no-cache/3664/3 "2021-06-30T17:53:47Z")
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.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [June 30, 2021, 7:53pm UTC](https://discourse.cmake.org/t/cmake-3-21-global-no-cache/3664/4 "2021-06-30T19:53:55Z")
I wonder how much of that is because of oddities between cache and local variable interactions (see [this issue](https://gitlab.kitware.com/cmake/cmake/-/issues/22038)) 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`.
---
### Author:  [@buildSystemPerson](https://discourse.cmake.org/u/buildSystemPerson)
#### Post date: [June 30, 2021, 9:03pm UTC](https://discourse.cmake.org/t/cmake-3-21-global-no-cache/3664/5 "2021-06-30T21:03:04Z")
Fair enough I’ll investigate further on this issue and see what I can find.
---
### Author:  [@marc.chevrier](https://discourse.cmake.org/u/marc.chevrier)
#### Post date: [July 1, 2021, 7:12am UTC](https://discourse.cmake.org/t/cmake-3-21-global-no-cache/3664/6 "2021-07-01T07:12:57Z")
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.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [July 1, 2021, 12:53pm UTC](https://discourse.cmake.org/t/cmake-3-21-global-no-cache/3664/7 "2021-07-01T12:53:24Z")
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.