Concerning CMake-presets (replacing our 'project variants')

Hi, back in Nov 2019 I asked here how I might define ‘project variants’ to define ‘super-options’ that would switch a set of options ON. Project variants?

@ben.boeckel suggested a nice solution: Project variants? and we have been using that ever since.

Would I be correct in thinking that a better solution now is to use cmake-presets?

We use Visual Studio and Visual Studio Code which don’t yet support cmake-presets, but I guess we could still use cmake-presets by passing the correct preset to CMake in the IDE CMake arguments field? (Hopefully, when full support for presets becomes available in the IDE, the underlying presets won’t need to change).

Best regards
David

Best regards
David

Presets could work, but requires a higher minimum CMake version to really be effective. That said, I’ve not investigated presets much myself.

I also don’t know how well the presets mechanisms allow changing decisions after the initial configure.

Cc: @kyle.edwards and @craig.scott who are far more familiar here.

The presets functionality probably maps a bit better to what you were originally trying to achieve with variants. My understanding is that presets are primarily intended for setting things up the first time you run CMake in a build directory. However, I’ve observed that you can re-run CMake with a preset and I think it re-applies things like CMake cache variables (i.e. overwriting any changes for those variables the preset defines), but you should check to confirm. I’m not sure if this overwriting behavior was intended, but it’s now the released behavior and it seems to be what you want here.

@ben.boeckel @craig.scott Thank you both for your replies.