I filed a CLion issue concerning a regression with not passing the build type when using CMakePresets.json. Some of the follow up Q&A Craig Scott kindly provided led me to have more questions, but Craig suggested I move the CMake specific discussion here. You can see my original CLion issue at: https://youtrack.jetbrains.com/issue/CPP-39536
A work around I thought of for this issue of CLion not passing the build type of the buildPreset would be to just set CMAKE_BUILD_TYPE in the configurePresets section. This begs the question, what even is the point of the buildPresets section in CMakePresets.json, if theoretically it could be accomplished with cacheVariables settings on a configurePreset? (CLion is happy to base a CLion Profile around either a configurePreset or a buildPreset.)
I get that multiple buildPresets could be associated with the same base configurePreset, but with inheritance the same could be said of configurePresets, which support both this and multiple inheritance. In configurePresets you can reference ${presetName} in a value, but there’s no variable to reference settings from the buildPreset, so I ended up having to essentially have a 1:1 structure of configurePresets for each build preset anyway since I use the ${presetName} as part of the build directory path in my presets.
(Refer to the CLion issue linked above to see the code of my CMakePreset.json. I could of course reproduce it here - let me know if you prefer I do that - I just didn’t want to make this post longer with it.)
Is there anything wrong with not using buildPresets (just relying on CLion’s willingness to base a profile around either a configurePreset or a buildPreset)? Or should I strive to make my configurePresets independent of build type?
(Now that I’m using vcpkg for my libraries, it’s no longer as necessary for me to control the build and especially install directories directly. When I originally crafted my custom CMakePresets.json, I was installing everything to a “…/Common” directory, but I needed to differentiate Emscripten Release builds from Native Release builds with unique paths as obviously you can’t mix the two in linking. I think the vcpkg triplet takes care of that for me now that I’m using ports.)
In the CLion issue report, Craig asked if I was using the Ninja Multi-Config generator. I’m not, but that brings up even more questions for me. If I were using it, how would I need to differently approach configurePresets and buildPresets, not to mention build/install directories? If you’ll forgive me expressing consternation at a feature I’m not even using, I am not clear how Multi-Config would work with different toolchain files and cross compilation (as Emscripten cross compilation build has to chainload the Emscripten toolchain file (in addition to the vcpkg toolchain)).
Would it be the case that I’d have two pairs of Ninja multi-config configurations, one for MinGW toolchain with Debug and Release build, and one for Emscripten toolchain with Debug and Release build? Or is it somehow possible to do all four with one configuration? How does it interact with vcpkg? Would I just not be able to do Multi-Config with my requirements?
Initially I had these questions because, between CLion breaking single-config CMakePresets.json by no longer passing CMAKE_BUILD_TYPE, and intonations about CLion adding support for Ninja Multi-Config, I was beginning to wonder if CLion was moving towards Multi-Config being the default and whether my setup (MinGW native plus Emscripten using CMakePresets.json) was going to become unsupported. However on reading more in CLion recent issues, it becomes clear they’re only adding (a bit more) support for it, not making it mandatory.
Nevertheless despite my concerns perhaps being moot (or hopefully soon will be, if CLion fixes Ninja single-config CMakePresets.json build Profiles), it might help me get a deeper picture of how this all works by (re)asking these questions here. Thanks.