22

As I am using cmake after editing CMakeLists.txt some variables wouldn't be loaded. If I had something defined with CACHE STRING it wouldn't let me to change it without forcing it or deleting cache.

So then why we have this CMakeCache.txt file. Is it even needed?

Ciro Santilli OurBigBook.com
  • 347,512
  • 102
  • 1,199
  • 985
oneat
  • 10,778
  • 16
  • 52
  • 70
  • 1
    For more details see [What's the CMake syntax to set and use variables?](https://stackoverflow.com/questions/31037882/whats-the-cmake-syntax-to-set-and-use-variables). – Florian Feb 10 '17 at 13:23

2 Answers2

21

Yes, it's certainly needed. CMake uses the cache when it's re-running itself during a build because a CMakeList file changed, or when you make rebuild_cache. It also loads the cache at start of a normal configure run.

The standard workflow for using CMake is as follows:

  1. Run CMake in an empty binary directory to generate the initial version of the project & cache
  2. In CMake GUI or ccmake or similar, inspect the cache variables set up by the initial run and modify them as you see fit.
  3. Re-run CMake (or just its Configure step if your UI offers that).
  4. Repeat steps 2&3 until you're satisfied with the configuration
  5. If you were only running Configure in 3, run Generate

You now have a buildsystem configured according to your taste.

For the above to work, user changes in the cache must take precedence over default cache values specified in CMakeLists.txt. Otherwise, the user changes from point 2 would be lost at next configure, overwritten by the project-specified defaults again.

That's why CMake commands set(var ... CACHE) do not modify the cache variable var if it already exists. Normally, your project should treat setting up the cache as providing user-tweakable defaults.

If you really need to override user choices in your project, you can:

  • add FORCE to the set command, or
  • use set without CACHE to set non-cache variables. Non-cache variables take precedence over cache variables of the same name.
TigerTV.ru
  • 1,058
  • 2
  • 16
  • 34
Angew is no longer proud of SO
  • 167,307
  • 17
  • 350
  • 455
  • 1
    And last but not least, the [load_cache](https://cmake.org/cmake/help/v3.4/command/load_cache.html?highlight=load_cache) command loads in the values from another project’s CMake cache. – Jean Davy Aug 31 '17 at 05:33
  • @Adam CMake presets a lot of variables, of course. There's no space here in comments to look at unrelated issues; do you want to post a question of your own? Ping me with a link to it if you want. – Angew is no longer proud of SO Sep 25 '19 at 11:02
  • @Angew Thanks alot. Though, I've just realized I edited a copy of my `CMakeLists.txt` I made for debugging the error, but run cmake against the original... Still I haven't resolved why my variables were overriden by the Cache. Though I haven't used `set`, I used `find_library` and probably that variables are cached? That explains why a totally different library was set in that variable -> I duplicated an existing `find_library` line of code and edited the variable name. By the time I edited the actual library name, the duplicate name plagued the cache forever. (IDE did cmake reload). – Adam Sep 25 '19 at 11:24
  • @Adam Yes, the results of `find_*` calls normally go into the cache. – Angew is no longer proud of SO Sep 25 '19 at 11:53
  • So I guess there should be a non-editable system cache, cached result would be used if the input to the cached function was the same. And another user editable local settings which would override everything. If I understood well the point of CMakeCache.txt – speed and user-editable local setting. – Adam Sep 25 '19 at 12:15
  • @Adam The primary purpose of CMakeCache.txt is to preserve the options when CMake is invoked by the build because a CMakeList has changed. What you describe are both intended uses too, of course. – Angew is no longer proud of SO Sep 25 '19 at 12:18
14

Motivating example

This is basically what https://stackoverflow.com/a/42160304/895245 mentions, but with a more explicit example to make it easier to understand.

Consider this use case:

git clone project
cd project
# Options ddfined with "option(" in CMakeLists.txt.
cmake -DOPT1=ON -DOPT2=OFF -DOPT3=ON .
make
# Create bugs (edit code).
make

Then, a few days later, a new directory is added to the project.

This means CMakeLists.txt was changed with a new add_subdirectory, and so we have to run cmake again to update our make files.

If we didn't have CMakeCache.txt, we would have to remember and type all options again:

git pull
cmake -DOPT1=ON -DOPT2=OFF -DOPT3=ON .
make

But because of the cache, we can do just:

cmake .
make
Ciro Santilli OurBigBook.com
  • 347,512
  • 102
  • 1,199
  • 985