presets: Add preset overriding

I have cherry-picked and updated !8227 (closed). @Arastais I hope you don't mind, if you want to take over again, feel free to cherry-pick this commit back.

TODO:

• Resolve cherry-pick issue from missing global environment
• Port the override to the other presets as well
• Add appropriate tests

Closes: #23046
Topic-rename: presets-override

changed the description

added 1 commit

• 9b51b86c - presets: Add preset overriding

Compare with previous version

added 1 commit

• 7a3bc4c3 - presets: Add preset overriding

Compare with previous version

marked the checklist item Port the override to the other presets as well as completed

added 1 commit

• f903f877 - presets: Add preset overriding

Compare with previous version

changed the description

mentioned in issue #23046

Question about this design, do we still want to add the override field, or should we just allow the presets to be overridden as long as the preset version >= 9?

Considering the restrictions on CMakeUserPresets.json/CMakePresets.json for the new/existing presets respectively, I am leaning to get rid of the override field requirement. What do you guys think?

What should happen if two different presets try to override the same preset? Which one should be retained, or should it be considered an error? Can you override an override? Such cases are likely to occur in more complex preset hierarchies, and in some cases the overrides will be identical, but in others they might not be. When not identical, the ordering of overrides then also becomes important. That may impact whether we can relax the constraint where presets must include all presets they inherit from (I still think we should keep that constraint, but I mention it here to highlight the complexities introduced when overriding presets becomes possible).

I have noticed something odd when repairing the tests: CMakeUserPresets.json is being read before CMakePresets.json. Why was it designed like this? @craig.scott do you have any insight on this?

I have tried simply inverting the read order, but it seems to be breaking some other tests with unreachable errors, so I would appreciate more insight on this.

added 1 commit

• 17507cf5 - presets: Add preset overriding

Compare with previous version

marked the checklist item Resolve cherry-pick issue from missing global environment as completed

marked the checklist item Add appropriate tests as completed

Hmm the failing test is quite weird. The regex seems just fine, but the fedora tests are reporting failure, even though the MacOS and windows one pass, and locally on Fedora this test passed as well.

Tests are passing now. The JSON validation did not happen locally for me maybe because of find_package(Python) vs find_package(Python 3.8), but that one is fixed now

added 15 commits

• 17507cf5...bd20084b - 14 commits from branch cmake:master
• 6311b27f - presets: Add preset overriding

Compare with previous version

added area:presets workflow:wip labels

added 164 commits

• 6311b27f...8728fb1e - 163 commits from branch cmake:master
• b730ee48 - presets: Add preset overriding

Compare with previous version

Regarding the design of this feature, I would say that each preset may be defined at most once each in CMakePresets.json and CMakeUserPresets.json. It can even be defined in files included by them. For example, if CMakePresets.json defines preset foo, and CMakeUserPresets.json includes foo.json, then foo.json can override preset foo. However, if CMakePresets.json also includes foo.json, that is an error, since preset foo is being defined more than once in CMakePresets.json.