CMake

CMake is not a build system — it's a build system generator. You describe your project once, in a CMakeLists.txt file, and CMake reads it and generates the actual build files for whatever tool you want to build with: Unix Makefiles, Ninja files, a Visual Studio solution, an Xcode project. That's the whole point of it: one project description, buildable on Linux, macOS, and Windows, with whichever compiler and build tool each platform prefers, without maintaining separate Makefiles by hand for each.

This is also why plain make or ninja alone can't build a CMake project directly from its CMakeLists.txt — there's a required generation step first (the "configure" step below) that turns the CMakeLists.txt into the Makefile or build.ninja file those tools actually understand.

sudo apt update
sudo apt install cmake -y

Two directories matter: the source tree (where your CMakeLists.txt and source files live) and the build tree (where CMake writes generated build files and compiled output). Always use an out-of-source build — a separate build directory, never mixed in with your source files. It keeps generated clutter out of version control, and lets you have multiple independent build configurations (a Debug build and a Release build, say) from the same source tree at once.

Every CMake project goes through three distinct steps:

cmake_minimum_required(VERSION 3.20)
project(MyApp VERSION 1.0 LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

add_executable(myapp src/main.cpp)

cmake_minimum_required must be the first line — it also sets which CMake behaviors ("policies") are active, so an old CMakeLists.txt keeps building the same way even on a newer CMake. project() declares the project name, version, and languages, and must come before any target is defined.

Modern CMake is built around targets, not global variables. A target is an executable or a library, and everything about how to build it — its sources, include paths, compile definitions, linked libraries — is attached directly to that target rather than set globally for the whole project.

These three keywords appear on every target_* command above, and they answer one question: does this property also apply to anything that links this target?

• PRIVATE — used only to build this target itself; consumers linking it never see it. Use this for implementation details (an internal helper library, a private include path).
• INTERFACE — not used to build this target at all, only passed on to whoever links it. The natural fit for header-only libraries, which have nothing to compile themselves.
• PUBLIC — both: used to build this target, and passed on to consumers. Use this when your public headers themselves depend on it (e.g. a header includes <boost/optional.hpp>, so consumers need that include path too).

Getting this right is what lets `target_link_libraries(app PRIVATE mylib)` automatically pull in everything mylib needs (its own PUBLIC and INTERFACE dependencies) without app having to know or re-declare any of mylib's internals.

Cache variables are written to CMakeCache.txt in the build directory and persist across reconfigures — that's how `cmake -B build` remembers your -D flags on the next plain `cmake --build build` without you repeating them. Deleting the build directory (or CMakeCache.txt specifically) resets everything back to defaults.

When a dependency isn't already installed on the system, FetchContent downloads it (usually from git) and builds it as part of your own project — no separate install step, no version mismatch between what you tested against and what's on the machine.

include(FetchContent)
FetchContent_Declare(
  googletest
  GIT_REPOSITORY https://github.com/google/googletest.git
  GIT_TAG        v1.14.0
)
FetchContent_MakeAvailable(googletest)

target_link_libraries(tests PRIVATE gtest_main)

FetchContent_MakeAvailable downloads the dependency once (cached for later builds), then runs its CMakeLists.txt as if it were add_subdirectory()'d in — its targets (gtest_main above) become directly linkable, same as any target you defined yourself.

CTest is CMake's bundled test runner — it doesn't run your tests itself, it just knows how to invoke whatever test executables you register, collect their pass/fail exit codes, and report a summary.

Generators split into two kinds, and it changes how CMAKE_BUILD_TYPE works:

• Single-config generators (Makefiles, Ninja) pick one build type — Debug, Release, etc. — at configure time, via CMAKE_BUILD_TYPE. To switch, reconfigure (or use a separate build directory per config).
• Multi-config generators (Visual Studio, Xcode) can hold every build type at once in one build directory. CMAKE_BUILD_TYPE is ignored; you choose the config at build time instead with `cmake --build build --config Release`.

A CMakePresets.json file (CMake 3.19+) lets a team commit named, shareable configure/build/test configurations to version control, instead of everyone remembering (or scripting) their own long strings of -D flags.

{
  "version": 6,
  "configurePresets": [
    {
      "name": "release",
      "binaryDir": "${sourceDir}/build/release",
      "cacheVariables": { "CMAKE_BUILD_TYPE": "Release" }
    }
  ]
}