Worked examples — CMake build types — Debug, Release, RelWithDebInfo

Statement. You run:

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build

With the GCC/Clang defaults, what flags reach the compiler, and are your assert() calls still alive?

Forecast. Guess the flag string and the assert answer before reading on.

1. Look up $T=\text{Release}$ in the flag-sum rule. The per-type variable CMAKE_CXX_FLAGS_RELEASE defaults to -O3 -DNDEBUG. Why this step? The type name is nothing but a lookup key; everything follows from which string it points at.
2. Add the always-on base. If CMAKE_CXX_FLAGS is empty (typical), the total is just -O3 -DNDEBUG. Why this step? The rule says base $+$ per-type; you must include both even when base is empty.
3. Read off NDEBUG's effect. -DNDEBUG defines NDEBUG, so every assert(x) expands to nothing — the checks are gone. Why this step? This is the one behavioural change (not just speed) that Release causes.

Answer. Flags = -O3 -DNDEBUG; asserts are disabled.

Verify. Sanity check the direction: -DNDEBUG present ⟹ asserts off ⟹ fewer runtime checks ⟹ faster. Consistent. The parent's flag table lists exactly -O3 -DNDEBUG for Release. ✓

Statement. You forgot the type:

cmake -S . -B build
cmake --build build

A colleague says "it's basically Release." Is it? What is the effective -O level?

Forecast. Fast or slow binary?

1. Substitute $T=\text{""}$ (empty) into the rule. With no type, CMAKE_CXX_FLAGS_<empty> is the empty string. Why this step? The "zero input" of this topic is an empty CMAKE_BUILD_TYPE, and the rule handles it just like any other value — it simply contributes nothing.
2. Total the flags. flags = CMAKE_CXX_FLAGS (base, usually empty) $+$ nothing = no -O, no -g, no -DNDEBUG. Why this step? Nothing injected means we fall back to the compiler's own default, which for GCC/Clang is -O0.
3. Interpret. -O0 ⟹ unoptimized ⟹ slow. It only looks like Release because the code is identical. Why this step? This is the whole trap: sameness of source ≠ sameness of speed.

Answer. Effective level is -O0. It is not Release — it can be many times slower.

Verify. Confirm with the cache after configuring: grep CMAKE_BUILD_TYPE build/CMakeCache.txt shows CMAKE_BUILD_TYPE:STRING= (empty). Empty in, empty flags out — matches the parent's "acts like -O0" warning. ✓

-g and -O at once Statement. Production crashes in the field. You need a fast binary and a backtrace that shows function names, not ??. Which type, and what exactly makes both possible?

Forecast. Can one binary be fast and debuggable? Or must you choose?

1. Recall the two knobs are independent switches (see the figure at the top). Speed is the -O dial; readability is the -g switch. Nothing forces them to move together. Why this step? The entire answer hinges on -g and -O being orthogonal — the parent's key insight.
2. Pick the type that flips both the right way. RelWithDebInfo = -O2 -g -DNDEBUG: high optimization and the symbol table. Why this step? We want the dial high and the map switch on — exactly this cell.
3. Reject the neighbours. Release drops -g (crash shows ??); Debug uses -O0 (too slow, different behaviour from real load). Why this step? Covering the why-not cases is what proves this cell is genuinely distinct.

Answer. RelWithDebInfo (-O2 -g -DNDEBUG).

Verify. Count the knobs: optimization present (-O2 ✓), symbols present (-g ✓), asserts off for prod speed (-DNDEBUG ✓). All three consistent with "fast but explainable." ✓

-DNDEBUG kill my own debug logging? Statement. You have this in your code:

assert(ptr != nullptr);           // (1)
if (verbose) log("entering foo"); // (2)
#ifndef NDEBUG
  dump_internal_state();          // (3)
#endif

You build Release (which injects -DNDEBUG). Which of (1), (2), (3) still run?

Forecast. Guess yes/no for each line.

1. Line (1): it's a standard assert. -DNDEBUG defines NDEBUG; the standard assert() macro expands to nothing when NDEBUG is defined. → removed. Why this step? assert is the only thing NDEBUG is contractually allowed to gate.
2. Line (2): a plain if. NDEBUG has zero connection to your own runtime if. → still runs (whenever verbose is true). Why this step? The name "NDEBUG" sounds like "no debugging," but it touches nothing you didn't wrap in it yourself.
3. Line (3): you wrote #ifndef NDEBUG yourself. With NDEBUG defined, #ifndef NDEBUG is false → the block is compiled out. → removed. Why this step? You opted this code into the same switch, so it shares assert's fate — but only because you chose to.

Answer. (1) removed, (2) kept, (3) removed.

Verify. Rule of thumb: NDEBUG affects assert() and anything you personally guarded with NDEBUG. Line (2) is guarded by nothing NDEBUG-related, so it survives. Matches the parent's "your own if(debug) logic is untouched." ✓

Statement. On Windows you run:

cmake -S . -B build -G "Visual Studio 17 2022" -DCMAKE_BUILD_TYPE=Debug
cmake --build build

You expected a Debug binary; you got a Release-flavoured one. Why? What's the correct command?

Forecast. Where did the -DCMAKE_BUILD_TYPE=Debug go?

1. Classify the generator. Visual Studio (also Xcode, Ninja Multi-Config) is a multi-config generator — see Single-config vs Multi-config Generators. Why this step? The flag-sum rule's "pick $T$ at configure time" story only holds for single-config generators; multi-config carries all types.
2. See why the flag is ignored. A multi-config build has no single baked-in $T$ at configure time, so CMAKE_BUILD_TYPE is silently dropped; the default active config is often Debug... but the default of the build command may differ per generator. Why this step? This is the degenerate edge: the "universal incantation" simply has no meaning here.
3. Choose the type at build time. You select the config when you build:

   cmake --build build --config Debug

   Why this step? Multi-config generators decide $T$ per build invocation, not at configure.

Answer. CMAKE_BUILD_TYPE is ignored by multi-config generators; use --config Debug at build time.

Verify. Consistency check: single-config = one $T$ frozen in the cache; multi-config = all $T$ available, chosen with --config. The command that actually names the type at build time is the correct one. ✓

Statement. You want a type named ASAN that gives light optimization, debug symbols, and AddressSanitizer. Write the CMake, then predict the flags a file compiled under -DCMAKE_BUILD_TYPE=ASAN receives.

Forecast. Will CMake reject an unknown type name?

1. Define the per-type variable.

   set(CMAKE_CXX_FLAGS_ASAN "-O1 -g -fsanitize=address"
       CACHE STRING "" FORCE)

   Why this step? The flag-sum rule looks up CMAKE_CXX_FLAGS_<TYPE>. If that variable exists, the type name is valid — types aren't a fixed enum, they're variable lookups (see CMake Cache Variables).
2. Configure with the new name. cmake -S . -B build -DCMAKE_BUILD_TYPE=ASAN. Why this step? Now $T=\text{ASAN}$ resolves to the string you defined.
3. Apply the rule. flags = base $+$ -O1 -g -fsanitize=address. Why this step? Same machine as every other type — no special case.

Answer. The compile line gets -O1 -g -fsanitize=address (plus base). A brand-new, fully working build type — see Sanitizers (ASan, UBSan).

Verify. The type is legal iff CMAKE_CXX_FLAGS_ASAN is set — which we set. Note it deliberately has no -DNDEBUG, so asserts stay live, which is what you want while hunting memory bugs. Self-consistent. ✓

Statement. Firmware for a microcontroller with tiny flash. The -O3 build doesn't fit. Which standard type minimises size, what flag does it inject, and what do you give up?

Forecast. Which knob position minimises bytes?

1. Identify the size-minimising -O position. -Os = "optimize for size": like -O2 but declines transforms that bloat code (aggressive inlining, loop unrolling — see Compiler Optimization Levels (-O0 to -O3)). Why this step? Size is a different objective than speed, so it needs its own dial position — the limiting case of "small," not "fast."
2. Map it to the standard type. MinSizeRel = -Os -DNDEBUG. Why this step? This is the only standard type built around -Os.
3. State the trade-off. No -g (smaller, but crashes show ??), asserts off (-DNDEBUG), and possibly slightly slower than -O3. Why this step? Every extreme buys one thing by spending another; naming the cost completes the case.

Answer. MinSizeRel → -Os -DNDEBUG; you trade away debug symbols and a little speed for smallest size.

Verify. Direction check: -Os targets bytes ⟹ smaller binary ⟹ fits flash. Matches the parent's "embedded / firmware, smallest size." ✓

Statement. A tricky exam question. You set:

cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug \
      -DCMAKE_CXX_FLAGS="-O2"

Debug implies -O0 via its default flags; you also forced -O2 into the base. The compiler sees something like -O2 ... -g. Which optimization level actually applies?

Forecast. Does -O0 (from Debug) or -O2 (your base) win?

1. Write the concatenation in order. flags = CMAKE_CXX_FLAGS $+$ CMAKE_CXX_FLAGS_DEBUG = -O2 $+$ -g. (Debug's default per-type string is essentially -g; the -O0 is the compiler's own default, not always an explicit flag.) Why this step? The flag-sum rule is ordered: base comes first, per-type second.
2. Apply the compiler's "last -O wins" rule. GCC/Clang honour the last optimization flag on the line. Here the only explicit -O is -O2 (from base), and Debug adds no explicit -O. Why this step? When two conflicting flags appear, order on the command line decides — this is the twist the question is testing.
3. Conclude. The binary compiles at -O2, with -g (Debug still contributed its symbols). Why this step? You accidentally built a RelWithDebInfo-like binary while asking for Debug.

Answer. -O2 wins; you get an optimized-but-symbol-rich build, not a true -O0 Debug.

Verify. Rule: later -O overrides earlier. Base string is emitted first, but it holds the only explicit -O, so it stands. Lesson: don't hand-inject -O into CMAKE_CXX_FLAGS; let the type own it. ✓