Building real projects: CMake, warnings, debuggers and sanitizers

Why a build system?

With two files you can type g++ main.cpp gst.cpp -o app. With 200 files, external libraries, debug and release builds, Windows and Linux, typing commands is impossible, and recompiling everything after a one-line change wastes minutes. A build system knows which files depend on which, rebuilds only what changed, and works the same on every machine. CMake is the most widely used build system generator for C++.

A typical project layout

billing/
├── CMakeLists.txt
├── include/billing/gst.h
├── src/gst.cpp
├── src/main.cpp
└── tests/gst_test.cpp

A minimal CMakeLists.txt

cmake_minimum_required(VERSION 3.20)
project(Billing LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

add_library(billing src/gst.cpp)
target_include_directories(billing PUBLIC include)

add_executable(billing_app src/main.cpp)
target_link_libraries(billing_app PRIVATE billing)

if (MSVC)
  target_compile_options(billing PRIVATE /W4)
else()
  target_compile_options(billing PRIVATE -Wall -Wextra -Wpedantic)
endif()

Modern CMake is "target-based": you describe targets (libraries and executables) and attach settings to them with target_* commands, instead of setting global flags. PUBLIC settings pass on to whoever links the target; PRIVATE ones do not.

Configure, build, run

cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug
cmake --build build
./build/billing_app

# Release build in a separate folder
cmake -S . -B build-release -DCMAKE_BUILD_TYPE=Release
cmake --build build-release

Using libraries

find_package(fmt CONFIG REQUIRED)               # a library installed on the system or via vcpkg/Conan
target_link_libraries(billing_app PRIVATE fmt::fmt)

include(FetchContent)                           # or download one at configure time
FetchContent_Declare(googletest
  GIT_REPOSITORY https://github.com/google/googletest.git
  GIT_TAG v1.15.2)
FetchContent_MakeAvailable(googletest)

Debug versus Release

Debuggers and sanitizers

• A debugger (gdb on Linux, lldb on macOS, the Visual Studio or VS Code debugger) lets you pause at a breakpoint, step line by line and inspect variables. Build with -g (Debug) first.
• AddressSanitizer (-fsanitize=address) finds out-of-bounds access, use-after-free and leaks.
• UndefinedBehaviorSanitizer (-fsanitize=undefined) finds signed overflow, bad shifts and similar undefined behaviour.
• ThreadSanitizer (-fsanitize=thread) finds data races (do not combine it with AddressSanitizer in the same build).
• Valgrind (Linux) finds memory errors without recompiling, but runs programs much slower.

target_compile_options(billing_app PRIVATE -fsanitize=address,undefined -fno-omit-frame-pointer)
target_link_options(billing_app PRIVATE -fsanitize=address,undefined)

Formatting and static analysis

clang-format formats code automatically from a .clang-format file, so reviews focus on logic, not spaces. clang-tidy and compiler warnings catch bug patterns and suggest modern replacements. Many teams run all of these in CI (continuous integration: automatic checks on every pull request).