RFC: add --build_type=<build_type> to cmake -S . -B build and more convenience aliases

Development
1

More shortcuts:

  • cmake -S . -B build --release
  • cmake -S . -B build --debug
  • cmake --build build --release (for multi-config generators)
  • cmake --build build --debug (for multi-config generators)
2

cmake already has --debug-* flags related to debugging cmake project code. I don’t think we should conflate that with build configurations.

Both CMAKE_BUILD_TYPE (for single-config) and CMAKE_CONFIGURATION_TYPES (for multi-config) support arbitrary configurations, and we’re certainly not going to have --$arbitrary_config flags.

For cmake --build with multi-config generators we already have --config $config.

3

No, I don’t suggest to add 'arbitrary_config`, it’s too intrusive, but for most used variants (debug/release, and potentially relwithdebinfo/minsizerel) it is looks like a shortcut
also, agreed with --debug-* flags (as I sometimes ago proposed one for packages )

For build_type I think that would be pretty simple to add it

4

For --build_type=<build_type>, we could consider offering --config $config at configure time as sugar for -DCMAKE_BUILD_TYPE=$config.

5

Oh, yes, agreed, also as kind of offtopic, I found that distinct utils (cmake, ctest, cpack) slightly diverges with this flag (don’t exactly remember details, will look on this)

6
  • cmake configure: would be --config <build_type>
  • cmake build: --config <build_type>
  • cmake install: --config <build_type>
  • ctest: --build-config <build_type>, -C <build_type>
  • cpack: -C <build_type>
7

Unfortunately for cpack, --config is already taken by --config <configFile>.

8

For ctest, we could consider adding --config $config as another alternative to -C $config and --build-config $config.

9

Potentially, we could allow cpack --config <something> to check if <something> is the name of an existing file. If it isn’t, treat it as a configuration instead. That might ultimately be less confusing, since then users can specify --config Release, etc. for all the tools. It could be argued that this may be better than the current inconsistency of cpack --config pointing to a file rather than a configuration.

1 Like
10

I’d be okay with that:

  • We should add a new cpack --config-file <file> for the original purpose.
  • We should try to validate the --config <config> value against available configurations.
11

In additional of aliases for flags: I also thought about --include-before/--dep-provider for -DCMAKE_PROJECT_TOP_LEVEL_INCLUDES for more clear semantic/distinction between simple “included before top level first project()” and “dependency provider”

12

A dependency provider is just one of the things you can do in a script named by CMAKE_PROJECT_TOP_LEVEL_INCLUDES. There is no way to inject a dependency provider other than through that specific mechanism (there are checks in the code to enforce this).

Where we already have an appropriate CMake cache variable for something, we should be careful about adding a corresponding command line for it as well. We have some precedent with things like CMAKE_TOOLCHAIN_FILE and --toolchain, but I would be reluctant to add too many more. The cmake executable already has many options. One of the common complaints about CMake is that there are multiple ways to do the same thing. In this case, I think we’re better off sticking with the CMAKE_PROJECT_TOP_LEVEL_INCLUDES as the one and only way to use a dependency provider, despite the long variable name.

1 Like