Debug vs Release in CMake

Question

In a GCC compiled project,

• How do I run CMake for each target type (debug/release)?
• How do I specify debug and release C/C++ flags using CMake?
• How do I express that the main executable will be compiled with g++ and one nested library with gcc?

Control

Answer 1

With CMake, it's generally recommended to do an "out of source" build. Create your CMakeLists.txt in the root of your project. Then from the root of your project:

mkdir Release
cd Release
cmake -DCMAKE_BUILD_TYPE=Release ..
make

And for Debug (again from the root of your project):

mkdir Debug
cd Debug
cmake -DCMAKE_BUILD_TYPE=Debug ..
make

Release / Debug will add the appropriate flags for your compiler. There are also RelWithDebInfo and MinSizeRel build configurations.

---

You can modify/add to the flags by specifying a toolchain file in which you can add CMAKE_<LANG>_FLAGS_<CONFIG>_INIT variables, e.g.:

set(CMAKE_CXX_FLAGS_DEBUG_INIT "-Wall")
set(CMAKE_CXX_FLAGS_RELEASE_INIT "-Wall")

See CMAKE_BUILD_TYPE for more details.

---

As for your third question, I'm not sure what you are asking exactly. CMake should automatically detect and use the compiler appropriate for your different source files.

Examination

You can also do a cmake -i .. instead, so cmake will run interactively, asking you which type of build you want (None, Release, Debug, MinSizeRel, RelWithDebInfo). – Inhume

@Inhume -i option results in this error message: The "cmake -i" wizard mode is no longer supported.. I'm using cmake 3.7.1 – Paranoiac

Nice observation. It seems it was deprecated since version 3.0.0. Reference. – Inhume

This is NOT an out of source build if you are creating a sub-directory! It is advised to create the build directory outside/above the source directory. – Dishearten

Note that if CMAKE_BUILD_TYPE is not set, cmake won't choose any default build type, hence the generated compiler command line won't be matching any build configuration. – Skirmish

Where can I see the default Compiler Flags and Definitions for Cmake in Release mode? Does it define _DNDEBUG automatically? – Veer

This seems a bit wasteful as much of what CMake discovers is the same for all builds. Also this gets a bit tedious when you have multiple configurations outside the release/debug choice. For example: > mkdir able && ( cd able && cmake -C ../config/able.cmake ../sources ) > mkdir baker && ( cd baker && cmake -C ../config/baker.cmake ../sources ) > mkdir charlie && ( cd charlie && cmake -C ../config/charlie.cmake ../sources ) Doubling for release/debug is tedious. > mkdir able.debug && ( cd able.debug && cmake -C ../config/able.cmake ../sources ) (etc.) – Incredible

Thanks for this answer. I keep coming back because I always forget when it comes to changing config from debug to release (and vice versa). Good reference. I bookmarked it. – Planar

NEVER set CMAKE_<LANG>_FLAGS_<CONFIG> from the toolchain file! Instead, set CMAKE_<LANG>_FLAGS_<CONFIG>_INIT. – Tarragon

The only one that really generated Debug/Release on RPi... Other options may seemingly work, but not effectively. – Seena

I have to run cmake --build . --config Release to get release build. If you omit --config Release you always get debug build, regardless of cmake -DCMAKE_BUILD_TYPE=Release .. in the previous command. (cmake 3.21) – Schleswig

Answer 2

A lot of the answers here are out of date/bad. So I'm going to attempt to answer it better. Granted I'm answering this question in 2020, so it's expected things would change.

---

How do I run CMake for each target type (debug/release)?

First off Debug/Release are called configurations in cmake (nitpick).

If you are using a single configuration generator (Ninja/Unix-Makefiles) you must specify the CMAKE_BUILD_TYPE.

Like this:

# Configure the build
cmake -S . -B build/ -D CMAKE_BUILD_TYPE=Debug

# Actually build the binaries
cmake --build build/

# Configure a release build
cmake -S . -B build/ -D CMAKE_BUILD_TYPE=Release

# Build release binaries
cmake --build build/

For multi-configuration generators it's slightly different (Ninja Multi-Config, Visual Studio)

# Configure the build
cmake -S . -B build

# Build debug binaries
cmake --build build --config Debug

# Build release binaries
cmake --build build --config Release

If you are wondering why this is necessary it's because cmake isn't a build system. It's a meta-build system (IE a build system that build's build systems). This is basically the result of handling build systems that support multiple-configurations in 1 build. If you'd like a deeper understanding I'd suggest reading a bit about cmake in Craig Scott's book "Professional CMake: A Practical Guide

---

How do I specify debug and release C/C++ flags using CMake?

The modern practice is to use target's and properties.

Here is an example:

add_library(foobar)

# Add this compile definition for debug builds, this same logic works for
# target_compile_options, target_link_options, etc.
target_compile_definitions(foobar PRIVATE
    $<$<CONFIG:Debug>:
        FOOBAR_DEBUG=1
    >
)

NOTE: How I'm using generator expressions to specify the configuration! Using CMAKE_BUILD_TYPE will result in bad builds for any multi-configuration generator!

Further more sometimes you need to set things globally and not just for one target. Use add_compile_definitions, add_compile_options, etc. Those functions support generator expressions. Don't use old style cmake unless you have to (that path is a land of nightmares)

---

How do I express that the main executable will be compiled with g++ and one nested library with gcc?

Your last question really doesn't make sense.

Muscatel

Kinda sucks that there aren't any warnings for multi-configuration generators when CMAKE_BUILD_TYPE is specified. I use Conan, which relies on it to figure out the build type. Because everything defaulted to the wrong values, my stuff got built with debug, while conan was (correctly) built with release, leading to a runtime library mismatch, and I assumed it was CMake setting it incorrectly. Spent far too many hours on that rabbit hole. I get that this is what CMake is supposed to do and all, but as a Linux main, this is utter pain. Real happy I don't do Windows regularly – Christian

You can use Ninja Multi-Config to test on linux. – Wendiwendie

Answer 3

For debug/release flags, see the CMAKE_BUILD_TYPE variable (you pass it as cmake -DCMAKE_BUILD_TYPE=value). It takes values like Release, Debug, etc.

https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/Useful-Variables#compilers-and-tools

cmake uses the extension to choose the compiler, so just name your files .c.

You can override this with various settings:

For example:

set_source_files_properties(yourfile.c LANGUAGE CXX) 

Would compile .c files with g++. The link above also shows how to select a specific compiler for C/C++.

Lucic

Answer 4

Instead of manipulating the CMAKE_CXX_FLAGS strings directly (which could be done more nicely using string(APPEND CMAKE_CXX_FLAGS_DEBUG " -g3") btw), you can use add_compile_options:

add_compile_options(
  "-Wall" "-Wpedantic" "-Wextra" "-fexceptions"
  "$<$<CONFIG:DEBUG>:-O0;-g3;-ggdb>"
)

This would add the specified warnings to all build types, but only the given debugging flags to the DEBUG build. Note that compile options are stored as a CMake list, which is just a string separating its elements by semicolons ;.

Protecting

Won't list(APPEND CMAKE_CXX_FLAGS_DEBUG "-g3") add a semicolon before -g3 terminated the command and starting a new command -g3 which will surely fail? – Ruddle

You're right CMAKE_CXX_FLAGS is not a cmake list but a string of space-separated command line flags. I find that behavior inconsistent... – Protecting

add_compile_options() is neat. It is complemented by add_link_options() for when you need to add options to the linker too such as -fsanitize=address. – Vitovitoria

Is this still the appropriate way in 2020 / cmake 3.17? That last line looks nasty – Bastion

@Bastion kinda. It is correct to use generator expressions. But the semi-colon thing isn't necessary and is honestly hard to read. See my answer. Also add_compile_options isn't always what you meant. It's a big hammer. – Muscatel

Answer 5

// CMakeLists.txt : release

set(CMAKE_CONFIGURATION_TYPES "Release" CACHE STRING "" FORCE)

// CMakeLists.txt : debug

set(CMAKE_CONFIGURATION_TYPES "Debug" CACHE STRING "" FORCE)

Neuroma

i don't understand why is this get down voted, it is real code which used in production, btw i don't care. – Neuroma

Maybe because according to the CMake docs CMAKE_CONFIGURATION_TYPES contains the possible values for CMAKE_BUILD_TYPE. So you should set the latter as the other answers suggest. Maybe your solution works because it limits the possible choices to the one you'd like to have. – Cutlass

Upvote because this will work. I love me some CMake but there are quirks and sometimes you need to use big hammer to make things work. I have some projects that for one reason or another will reject the command line flag. – Anglophile

Here's some additional information on why the setting may not work: https://mcmap.net/q/74224/-cmake_build_type-is-not-being-used-in-cmakelists-txt – Venu

Answer 6

If you want to build a different configuration without regenerating if using you can also run cmake --build {$PWD} --config <cfg> For multi-configuration tools, choose <cfg> ex. Debug, Release, MinSizeRel, RelWithDebInfo

https://cmake.org/cmake/help/v2.8.11/cmake.html#opt%3a--builddir

Physostomous

I've tried to play with --config option without any result. It doesn't affect $<CONFIG> variable as -DCMAKE_BUILD_TYPE= does. – Linskey

You meant cmake --build $PWD --config <cfg>, BTW. – Incredible

CMake version 3.20.1: cmake --help does not show that --config is a valid argument. Perhaps it has been deprecated? When I use --config cmake returns CMake Error: Unknown argument --config – Gelsenkirchen