Should cache values in CMakePresets.json "only" be "presets" , how are IDEs supposed to handle them ?

Development
1

Hi,

in CMakePresets.json I can define the values of cmake cache variables.

I was assuming that the values I set there are “only” presets, i.e. the values used when initially running cmake. For that I provided some configure-presets which set some variables to useful default values for a certain group of developers in my project.

I was assuming that it will still be possible to use cmake-gui to change the value of these variables afterwards (since the presets are “only” pre-sets I thought).

But, when using VS Code, this doesn’t work. I am not able anymore to change cache variables via cmake-gui which are defined in a preset. Whenever VS Code decides that cmake must run again, the presets are applied again, discarding the changes I did to the cache variables.

Is this how the presets should be used by IDEs ?

It’s a bit unfortunate, since developers now have to learn that changing the options of a cmake-based project via cmake-gui may be overridden by some other mechanism, the presets json file.

This is slightly related to “presets: combinatorial explosion” (https://gitlab.kitware.com/cmake/cmake/-/issues/22538), since my solution was to the issue was to create an additional set of presets, with those variables set differently. :-/

Getting slightly off-topic: I don’t understand why e.g. VS Code and VS basically require CMakePresets. For a not-total-beginner cmake user it is not hard to create a build tree, and I think users have learned how to use e.g. cmake-gui over the years. It would be so easy for IDEs to just keep that working, and adding the possibility to “load” an (any) existing cmake build tree, by simply putting a file API query file in the build tree and read all necessary information from the response files. If the reply file exists already in the build tree, they could simply read it and be done, instead of forcing a cmake rerun (which can actually take some time under Windows). This would be so easy, and I would still be able to create any number of custom build trees for my projects and use them in VS Code. Instead they force users to add a preset for every build tree (as far as I can see).
Btw. I created a ticket for VS Code early last year, in case you want to support this idea: Create configure- and build-presets on-the-fly from an existing build tree · Issue #4293 · microsoft/vscode-cmake-tools · GitHub

Alex

2

When I tried to use VS Code with source code in WSL, it also worked without presets. But it does only offer that if no preset files is present…rather dumb if you ask me. That’s why I currently prefer wrapper scripts instead.

IMHO presets should only apply on the (re-)creation of a build tree. What does CMake do internally when changing a cmake file and starting a build?

3

When simply building (by calling make/ninja/cmake –build), or when simply rerunning cmake (e.g. by cmake . or make rebuild_cache) it does not reapply the variable values from the presets. When rerunning cmake with --preset foo , it does reapply the variable values from the presets.

When developing, I think the only reason to run cmake with the –preset option might be to reapply the variable, but actually I think developers normally wouldn’t do it.