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.

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

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.

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

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

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.

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

There is for some toolchains on Windows, such as for MSVC. 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.