# CMAKE\_BUILD\_TYPE IGNORED

**URL:** https://discourse.cmake.org/t/cmake-build-type-ignored/2230
**Category:** Usage
**Created:** [November 24, 2020, 8:52pm UTC](https://discourse.cmake.org/t/cmake-build-type-ignored/2230 "2020-11-24T20:52:58Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![mcandre](https://discourse.cmake.org/user_avatar/discourse.cmake.org/mcandre/32/973_2.png) [@mcandre](https://discourse.cmake.org/u/mcandre)
#### Post date: [November 24, 2020, 8:52pm UTC](https://discourse.cmake.org/t/cmake-build-type-ignored/2230/1 "2020-11-24T20:52:58Z")

</div>

A few UX notes about build types

- Why not default to Release type, for both cmake and ctest? Let’s have the simple project case be the easiest to implement!
- ctest and cmake should accept the same CLI flags for overriding build type.
- CMAKE\_BUILD\_TYPE should apply to ctest as well as cmake.
- CMAKE\_BUILD\_TYPE is currently ignored for MSVC builds (cmake v3.19)

–

Separate concern, I noticed that RHEL suffixes the CLI tools with “3”. That does help to disambiguate for any cmake v2 or cmake v4 projects. But it would be good to register cmake with update-alternatives to provide the conventional “cmake” ,“ctest” (no suffix) commands.

This helps to make cross-platform build scripts more consistent and portable. For example, add symlinks when the cmake package is installed.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [November 24, 2020, 10:13pm UTC](https://discourse.cmake.org/t/cmake-build-type-ignored/2230/2 "2020-11-24T22:13:46Z")

</div>

I think you’re confusing different types of generators here. There are two general classes:

- single-config generators (Makefiles, Ninja, etc.)
- multi-config generators (VS, Xcode, Ninja Multi-Config)

The former only support a single build configuration per generate step. The latter defer the selection of the build type to build time (for which `cmake` and `ctest` have flags for selecting them).

> [@mcandre](#):
>
> Why not default to Release type, for both cmake and ctest? Let’s have the simple project case be the easiest to implement!

There is no default for `CMAKE_BUILD_TYPE`. I suspect this is a historical artifact. I don’t know what would be the implications of changing the default.

> [@mcandre](#):
>
> ctest and cmake should accept the same CLI flags for overriding build type.

For single-config generators, this would require rerunning the build system. For the multi-config generators, there are flags for selecting the configuration (though they are not the same).

> [@mcandre](#):
>
> CMAKE\_BUILD\_TYPE should apply to ctest as well as cmake.

It does for single-config generators in that only the selected configuration is available for testing.

> [@mcandre](#):
>
> CMAKE\_BUILD\_TYPE is currently ignored for MSVC builds (cmake v3.19)

I believe you mean Visual Studio builds. MSVC works just fine with `CMAKE_BUILD_TYPE`…in single-config generators.

Please feel free to offer suggestions for improving the documentation around `CMAKE_BUILD_TYPE`.

> [@mcandre](#):
>
> Separate concern

Please use a separate thread for this. I’ll answer once that is made.

---

<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: [November 25, 2020, 12:15pm UTC](https://discourse.cmake.org/t/cmake-build-type-ignored/2230/3 "2020-11-25T12:15:14Z")

</div>

> [@ben.boeckel](#):
>
> There is no default for `CMAKE_BUILD_TYPE` .

There is for some toolchains on Windows, such as [for MSVC](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.19.1/Modules/Platform/Windows-MSVC.cmake#L152). Historically it was needed because the MSVC runtime library selection flags were in the per-config `CMAKE_<LANG>_FLAGS_<CONFIG>` variables, and we always needed to make sure one was used. Since policy CMP0091 that is no longer the case, but the behavior remains for compatibility.
