Hi, I’ve been experimenting with Presets a bit in conjunction with Ninja Multi-Config generator.
I encountered this issue,(simplified for the sake of this not being too long):
{
"version": 3,
"configurePresets": [
{
"name": "multi",
"generator": "Ninja Multi-Config"
},
{
"name": "with-cuda"
"inherits": "multi",
"cacheVariables" : # enable cuda here etc.
},
... more combinations with multi as base config.
],
"buildPresets": [
{
"name": "release",
"configurePreset": "multi",
"configuration": "Release"
},
{
"name": "debug",
"configurePreset": "multi",
"configuration": "Debug"
}
... now we have to add release and debug for configurePreset with-cuda and every other preset inheriting from multi.
],
"testPresets": [
... same issue as with buildPresets
]
}
Now from documentation it seems like for each configure target I’d have to define 2 (or more) buildPresets (rel, debug, relwithdebinfo). This makes the CMakePresets.json quite repetitive. I do not know why the design decision to require configurePreset to be present in buildPreset was made so take what follows as thoughts of an user which might be incorrect/coming from misunderstanding the architecture.
What I feel like would be a good compromise is to make configurePreset in buildPreset mean this is the base I need, anything inheriting from the preset is also fine, or maybe a configurePreset: "*" to specify to just use currently active configurePreset.
When I posted this as an issue in the CMake repo, a workaround was suggested but that only works from commandline. For example VSCode integration won’t play nice with multi-config generators until this is somehow solved (or we’ll just have to accept the verbosity).