1

We currently have a multi-platform, multi-compiler build for a C++ program based on a bunch of custom ad hoc scripts. I'm investigating switching over to Modern CMake (with "modern" used in the sense described here), and trying to do it in a "best practices" way as much as possible. (For example, doing so in a fashion which will work with all sorts of generator types.)

The issue I'm running into is that we have more build types (build modes? configuration types?) than just the standard Release/Debug/RelWithDebInfo/MinSizeRel. I'm wondering how to implement these with Modern CMake.

From what I can tell (e.g. from the FAQ), the "traditional" way to add new build modes would be to hardcode various variables with names containing the new mode name. I'm skeptical about this approach for several reasons. First off, the list of variables which need to be set is left rather unclear. Secondly, it looks like the Modern CMake approach is to attach compiler flags to targets, rather than messing with global settings, and I'm not sure how to square that with the build type globals. Lastly, given the hope to have things working in a multi-compiler/cross platform fashion, I'm a bit concerned that Release/Debug/etc. works "automagically" on multiple platforms/compilers, but the custom build modes seem to require hard coding things for a particular platform/compiler. I realize that some platform/compiler specific code may be unavoidable, but I'm hoping to minimize that to the extent possible, and do that robustly.

What's the recommended best practices "Modern CMake" way of creating custom build/configuration types/modes? Specifically one which is most extensible for use with multiple compilers and platforms, and works robustly with both multi-configuration and single-configuration generators?

R.M.
  • 3,461
  • 1
  • 21
  • 41
  • Note: this question _sounds_ extremely similar to [this](https://stackoverflow.com/q/11437692/11107541) and [this](https://stackoverflow.com/q/45475319/11107541), but I don't want to call duplicate because those questions were resolved as misunderstandings and contextual mistakes by the askers. To me, their answers didn't address the question they asked, whereas **this** one is clear and shows research effort. I think it will bring much more value than those existing ones I found. If I do later find a good existing question, then I will vote to close this as a duplicate. – starball Oct 12 '22 at 04:44
  • The only thing I see that is undersirable about this question is that it brings up a lot of concerns that someone else (not me) might find as meriting separate questions and making this post lack focus. I think the various concerns are okay as one post, and that they will encourage _higher quality_ answers. – starball Oct 12 '22 at 04:45
  • 1
    "_(e.g. if a new mode is something like "Release, but with asserts", is there a "simple" way to do that?)_". As far as I know, there is no existing CMake-builtin functionality that makes it easy to create copies of configurations. There might be module libraries out there that include such functionality though. Here's where I draw the line on what should be a separate question. I would tell you to ask this separately, but it seems to already be asked [here](https://stackoverflow.com/q/43746829/11107541). Could you edit it out of your question? It's endangering your otherwise good post. – starball Oct 12 '22 at 05:29
  • There is no such thing in CMake like "a universal guide in creating custom build type". Taking that into account, your question post becomes consisted from **many independent questions**, each of which should be asked as a separate question on Stack Overflow. "First off, the list of variables which need to be set is left rather unclear." - You aren't **forced** to set any variable beyond `CMAKE_BUILD_TYPE`/ `CMAKE_CONFIGURATION_TYPES`. If you want to know which variable you **may** set for add some feature, then look into variables contained `CONFIG` in their name. – Tsyvarev Oct 12 '22 at 10:00

0 Answers0