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

**URL:** https://discourse.cmake.org/t/rfc-add-build-type-build-type-to-cmake-s-b-build-and-more-convenience-aliases/13503
**Category:** Development
**Created:** [January 28, 2025, 6:14pm UTC](https://discourse.cmake.org/t/rfc-add-build-type-build-type-to-cmake-s-b-build-and-more-convenience-aliases/13503 "2025-01-28T18:14:50Z")
**Posts on this page:** 15
**Page:** 1

<div class="post-metadata">

### Author: ![leha-bot](https://discourse.cmake.org/user_avatar/discourse.cmake.org/leha-bot/32/921_2.png) [@leha-bot](https://discourse.cmake.org/u/leha-bot)
#### Post date: [January 28, 2025, 6:14pm UTC](https://discourse.cmake.org/t/rfc-add-build-type-build-type-to-cmake-s-b-build-and-more-convenience-aliases/13503/1 "2025-01-28T18:14:51Z")

</div>

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)

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [January 28, 2025, 6:24pm UTC](https://discourse.cmake.org/t/rfc-add-build-type-build-type-to-cmake-s-b-build-and-more-convenience-aliases/13503/2 "2025-01-28T18:24:33Z")

</div>

`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`.

---

<div class="post-metadata">

### Author: ![leha-bot](https://discourse.cmake.org/user_avatar/discourse.cmake.org/leha-bot/32/921_2.png) [@leha-bot](https://discourse.cmake.org/u/leha-bot)
#### Post date: [January 28, 2025, 6:39pm UTC](https://discourse.cmake.org/t/rfc-add-build-type-build-type-to-cmake-s-b-build-and-more-convenience-aliases/13503/3 "2025-01-28T18:39:55Z")

</div>

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](https://gitlab.kitware.com/cmake/cmake/-/issues/21880) )

For build\_type I think that would be pretty simple to add it

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [January 28, 2025, 6:44pm UTC](https://discourse.cmake.org/t/rfc-add-build-type-build-type-to-cmake-s-b-build-and-more-convenience-aliases/13503/4 "2025-01-28T18:44:38Z")

</div>

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

---

<div class="post-metadata">

### Author: ![leha-bot](https://discourse.cmake.org/user_avatar/discourse.cmake.org/leha-bot/32/921_2.png) [@leha-bot](https://discourse.cmake.org/u/leha-bot)
#### Post date: [January 28, 2025, 6:45pm UTC](https://discourse.cmake.org/t/rfc-add-build-type-build-type-to-cmake-s-b-build-and-more-convenience-aliases/13503/5 "2025-01-28T18:45:30Z")

</div>

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)

---

<div class="post-metadata">

### Author: ![leha-bot](https://discourse.cmake.org/user_avatar/discourse.cmake.org/leha-bot/32/921_2.png) [@leha-bot](https://discourse.cmake.org/u/leha-bot)
#### Post date: [January 28, 2025, 6:48pm UTC](https://discourse.cmake.org/t/rfc-add-build-type-build-type-to-cmake-s-b-build-and-more-convenience-aliases/13503/6 "2025-01-28T18:48:50Z")

</div>

- 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>`

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [January 28, 2025, 6:55pm UTC](https://discourse.cmake.org/t/rfc-add-build-type-build-type-to-cmake-s-b-build-and-more-convenience-aliases/13503/7 "2025-01-28T18:55:17Z")

</div>

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

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [January 28, 2025, 6:57pm UTC](https://discourse.cmake.org/t/rfc-add-build-type-build-type-to-cmake-s-b-build-and-more-convenience-aliases/13503/8 "2025-01-28T18:57:47Z")

</div>

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

---

<div class="post-metadata">

### Author: ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [January 29, 2025, 5:23am UTC](https://discourse.cmake.org/t/rfc-add-build-type-build-type-to-cmake-s-b-build-and-more-convenience-aliases/13503/9 "2025-01-29T05:23:31Z")

</div>

> [@brad.king](#):
>
> Unfortunately for `cpack`, `--config` is already taken by `--config <configFile>`.

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.

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [January 29, 2025, 2:54pm UTC](https://discourse.cmake.org/t/rfc-add-build-type-build-type-to-cmake-s-b-build-and-more-convenience-aliases/13503/10 "2025-01-29T14:54:15Z")

</div>

> [@craig.scott](#):
>
> 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.

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.

---

<div class="post-metadata">

### Author: ![leha-bot](https://discourse.cmake.org/user_avatar/discourse.cmake.org/leha-bot/32/921_2.png) [@leha-bot](https://discourse.cmake.org/u/leha-bot)
#### Post date: [January 29, 2025, 5:38pm UTC](https://discourse.cmake.org/t/rfc-add-build-type-build-type-to-cmake-s-b-build-and-more-convenience-aliases/13503/11 "2025-01-29T17:38:32Z")

</div>

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”

---

<div class="post-metadata">

### Author: ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [January 30, 2025, 8:25am UTC](https://discourse.cmake.org/t/rfc-add-build-type-build-type-to-cmake-s-b-build-and-more-convenience-aliases/13503/12 "2025-01-30T08:25:17Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [February 10, 2025, 11:43am UTC](https://discourse.cmake.org/t/rfc-add-build-type-build-type-to-cmake-s-b-build-and-more-convenience-aliases/13503/13 "2025-02-10T11:43:18Z")

</div>

> [@brad.king](#):
>
> We should try to validate the `--config <config>` value against available configurations.

We could only do that for multi-config generators. For those, we have `CMAKE_CONFIGURATION_TYPES`, but for single-config generators, we have no such list we can consult. We can’t assume just the standard predefined types because projects and users can define their own custom build types.

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [February 10, 2025, 2:13pm UTC](https://discourse.cmake.org/t/rfc-add-build-type-build-type-to-cmake-s-b-build-and-more-convenience-aliases/13503/14 "2025-02-10T14:13:12Z")

</div>

Since the config-file format is `.cmake` maybe we can look for that extension.

---

<div class="post-metadata">

### Author: ![leha-bot](https://discourse.cmake.org/user_avatar/discourse.cmake.org/leha-bot/32/921_2.png) [@leha-bot](https://discourse.cmake.org/u/leha-bot)
#### Post date: [February 22, 2025, 5:33pm UTC](https://discourse.cmake.org/t/rfc-add-build-type-build-type-to-cmake-s-b-build-and-more-convenience-aliases/13503/15 "2025-02-22T17:33:30Z")

</div>

I think that flag is more robust for early typos detection, as I saw many typo errors with -DCMAKE\_PROJECT\_TOP\_LEVEL\_INCLUDES, and it was kind of frustration

I agree that may be multiple flags would be an additional source of confusion, so I think we could add only one (I also thought about `-FI` (force includes flag from MSVC) as conceptually similar flag, but it’s kind of bikeshedding)