vscode-cmake-tools
vscode-cmake-tools copied to clipboard
microsoft
Allow overriding/adding to cache variables when using CMake Presets
Brief Issue Summary
The current CMake Presets path does not allow for easy adjustments to the configuration by overriding/adding to cache variables.
Expected:
cmake.configureSettings override/add to the variables from configurePresets.cacheVariables
When calling cmake from the command line,
cmake --preset default -DCMAKE_VERBOSE_MAKEFILE=ON will override/add the variable to the configuration.
Suppose you have 2-3 configure presets, 1-2 build presets for each, and 1-2 test presets. Now you want to adjust the prefix path, enable verbose makefiles, export compile commands, use a compiler launcher etc., you would need to write up to 12 user presets just to add a single variable to the presets.
Thank you for the suggestion. We may not be able to address this immediately and we will monitor the community reactions to such a feature. In the meantime, you can use presets inheritance to achieve this scenario.
@andreeis Thank you for your reply. This would also be one possible way to solve the issue described in https://github.com/microsoft/vscode-cmake-tools/issues/1829 as well as https://github.com/microsoft/vscode-cmake-tools/issues/1835
As evidenced by other linked issues, this is a general problem with using presets. CMake allows command-line options to override things specified in presets, but this extension silently ignores most of its own settings that would be applicable in this manner. Another setting that I missed was "cmake.buildToolArgs", but the problem is definitely much wider than that.
It's been over a year since this was reported, with no traction. Consider this a friendly refresh/ping to see if it's possible to get a move on it.
One loosely-related frustrating thing about this is that it's tempting to use CMakeUserPresets.json in order to provide overrides, however there doesn't seem to be a way to use this "user" presets file to amend existing configure/build/test presets. That appears to be CMake's own shortcoming, but I thought I'd mention it in case it sparks illuminating discussion.
Just got confused that some configuration was different on our development machines ever since we switched to using CmakePresets.json.
Turns out we were previously injecting a variable via cmake.configureSettings which does not seem to work when using CMake Presets (nor does cmake.configureArgs).
We use it to adjust the output of certain commands so that it is something that VS Code can directly understand (rather than an XML or JSON file for our CI environment).
Is there currently a way to still inject a cache variable via this extension when using CMake Presets?
I would rather not have to duplicate all our different presets and as far as I know it's allowed to pass both -D and --preset to CMake.
Found a workaround for my use case by using cmake.cacheInit. Less elegant as it requires an additional CMake file (that does the cache initialization), but it works for me and is still better than duplicating the presets in my opinion.
Found a workaround for my use case by using
cmake.cacheInit. Less elegant as it requires an additional CMake file (that does the cache initialization), but it works for me and is still better than duplicating the presets in my opinion.
I was getting excited there for a minute, because this issue is bothering pretty much everyone I know who is using CMakePresets.json with VSCode.
Sadly, the initial cache is overridden by CMakePresets.json, so it does not solve the original issue.
Might be related: https://github.com/microsoft/vscode-cmake-tools/issues/3129
