Add CMake presets

[eddyashton]

We have a collection of sensible build targets, represented by the different jobs in the CI (eg: normal, debug, clang-tidy, ASAN, TSAN). Each includes some common args (-GNinja), some explicit args for the target build type (-DTSAN=ON), and some further flags to support this (eg excluding other features -DUSE_SNMALLOC=OFF, enabling other features -DWORKER_THREADS=2, disabling slow tests -DLONG_TESTS=OFF).

If one of these fails in CI, and you want to repro locally, you might need exactly the same arguments. Currently that's done by finding the correct bit of YAML and copy-pasting.

I think CMake Presets solve this in a cleaner way. So we'd create a CMakePreset.json specifying these arguments, and then can simply call cmake --preset TSAN either locally or in the CI, to get a consistent collection of args (and metadata and flags and who knows what else might be useful).

[achamayou]

@eddyashton is there a way to pass additional arguments still?

[maxtropets]

But you'd still need to find the correct presets in yml to repro smth?..

To me, finding flags isn't a big of a deal, and as far as I'm concerned this doesn't help getting rid of looking them up.

What I'm afraid of is more CMake magic, like going through extra steps on your way of finding out how to enable/disable behaviour, but maybe I'm overreacting here.

[achamayou]

An example of presets: https://github.com/microsoft/scitt-ccf-ledger/blob/main/app/CMakePresets.json

Adding a layer in front of CMake may be a mixed blessing. We've done that with CTest, to deal with venvs, and it's not been great. The settings probably work ok with very few flags (7.x is better, since the platforms are gone), but suffer from combinatorial expansion otherwise.

There's an argument that keeping track of valid combination of flags in presets means that we can drop the logic we currently have in the cmake files itself to gate incompatible combinations, but that makes direct CMake usage less safe than now.

I think on the whole I'm mildly against it because it feels like it would make the build infra a somewhat deeper by adding a layer but not substantially narrower, and copy pasting build/test lines from the CI is still very much what we will do, so the length of the line isn't terribly important. I wouldn't mind looking at a draft though, in case I'm wrong!