Hello, I am new to development for CMake and have a few ideas I want to suggest around Presets. I have provided all three things below, but I can break these out into separate posts if the powers that be decide that is cleaner.
I have started work on all three of these (with a working implementation of #2)
Patch 1: Add “Reload Presets” to QT GUI
This one is simple, for a workflow where one is actively writing presets, they might want a button to do this in the GUI to quickly validate changes. I have added this to the right of the preset selector in the config.
I hope this patch is uncontroversial, and merging it should give me a way to get myself acquainted with CMake’s review process.
Patch 2: Proposal - For the next Presets schema version, enable macros for the “Build Presets” > “ConfigurePreset” value.
Use case: I can think of two reasons why one might want this. I myself want it to keep my build presets slightly cleaner in the case my build preset name matches my configure preset name - which is most of the time IME. I have created a gist to show what I mean - yes, it’s a small simplification, but imagine this change with a few dozen build presets.
The second reason is this would allow users with advanced build preset needs to use vendor macros in the ConfigurePreset field. I don’t have need for this personally, but I could see it being useful for presets generated by a development environment.
I think this shouldn’t be too controversial, because it doesn’t force users into a new pattern, but I am welcome to feedback on whether or not this is a good idea.
Patch 3: Proposal - CMakeUserPresets entries should overrule CMakePresets entries when a preset name matches. This substitution should be done before the inheritance tree is processed.
Use case: I have a custom set of environment variables that I want to generate for my users which is environment dependent. These can’t be added to CMakePresets.json programmatically since we have it checked into VCS. I want these envvars in the user presets to overwrite the non-user presets, but I understand this isn’t the case currently.
I anticipate this change to be controversial, as it could break some behavior users expect. However, I would argue that no user should have presets with the same name currently, so I doubt this would actually cause any tangible issues for CMake Presets users.
As a counter-suggestion in anticipation with this, could we have a switch that’s off by default in cmake.exe - say, “–allow-preset-overrides” which lets users have multiple overrides with the same name in their presets, and gives the last one precedence?