Add a CMakePresets.json file with some common presets.

[benvanik]

https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html

vscode now supports this: https://devblogs.microsoft.com/cppblog/cmake-presets-integration-in-visual-studio-and-visual-studio-code/#cmake-presets-in-the-cmake-tools-extension-for-visual-studio-code

would be good to have some of our common configurations (tracing, size-optimized, release+asserts, asan, etc) via this mechanism.

[ScottTodd]

Here's a draft of a presets file: https://gist.github.com/ScottTodd/dd4100b22d085723baa3679a7cfbf544

Some impressions:

Inheritance is only sufficient for certain setups. Others would need composition/optionality/scripting support. For example: if I want to make some setting (e.g. which backends to build, whether to use ccache) optional, I would need to create two configure presets: setting_enabled and setting_disabled. To then build, I would need to create a matching build preset for each: setting_enabled and setting_disabled. That leads to a state space explosion if build presets then include other options.

Branching by platform (e.g. IREE_ENABLE_LLD, IREE_BUILD_TRACY, -DCMAKE_C_COMPILER=clang vs MSVC) won't really work effectively because of that inheritance setup.

"workflow presets" let you group configure -> build -> test -> etc. steps. They can only be used with a shared configure step though, so you can't have a crosscompilation workflow that runs configure (host) -> build (host) -> install -> configure (target) -> build (target).

Now... we may be able to create something workable with:

• a base configure/build preset in CMakePresets.json that sets a minimal list of options (-DIREE_ENABLE_ASSERTIONS=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo, etc.)
• some common presets that we currently have scripts for (build_runtime.sh, build_runtime_small.sh)
• a script that helps generate a platform-specific CMakeUserPresets.json, maybe with some CLI magic for "do you want to use ccache? which backends do you want?"

[GMNGeoffrey]

Even if the configs are totally flat, I think they would be quite useful. If we end up with a bunch of repetition we could even do our own composition in a somewhat-sane language like Python and then generate a bunch of json files

[benvanik]

Regardless of what we do as long as this is CMakePresets.json.template or something then we can land an iterate. One of the many major issues with presets is that the presence of the file will trigger most IDE's/editors to switch to using them and if your configuration isn't supported it gets really painful (nothing will work until you delete the file or go set environment variables before launching the editor, which sucks). This would let us side-step some of the hierarchy issues to start as we could have a template for primarily compiler + host runtime usage and one or more for specific runtime/cross-compiling usage.

[ScottTodd]

https://github.com/openxla/iree/pull/15581 added a few presets to build_tools/cmake/presets/. Still need to have a few people give them a try and offer feedback (see Stella's request on Discord here), then advertise them in our docs.