An introduction to the build pipeline, and how we can orchestrate it manually

Before working with CMake, it's useful to understand the tools it orchestrates. This lesson guides you through setting up a C++ toolchain.

Building C++ Programs

Walking through the steps of the C++ compilation process, from source code to machine code.

The Compilation Pipeline

The linker's role in the build process, how it resolves symbols to combine object files, and how to troubleshoot common errors.

Object Files and the Linking Process

The difference between static and dynamic libraries, how to create them, and the trade-offs between them.

Static and Shared Libraries

The C++ Build Process

Recommended approaches for managing large projects and the libraries that they depend on

Learn how to structure your C++ projects for scalability and maintainability, from basic directory layouts to managing multiple modules.

Organizing a C++ Project

Learn to manage third-party libraries in C++, covering include/library paths, static vs. shared libraries, versioning, and platform differences.

Managing Libraries and Dependencies

An introduction to traditional build tools like Makefiles and IDE projects, highlighting the maintenance, scalability, and cross-platform challenges that result

Automated Build Systems and Their Limitations

Project Structure and Dependency Management

Setting up CMake and creating your first project

An introduction to CMake, the cross-platform, open-source meta-build system that solves the core challenges of C++ project management.

Why CMake?

A step-by-step guide to installing CMake. We'll explore command-line, GUI, and IDE workflows, and how to configure your compiler.

Setting Up a CMake Environment

Creating the bare minimum `CMakeLists.txt` file and build up to a project with an executable and a library, learning the fundamental commands along the way.

Writing a CMakeLists File

Learn the two-stage process of building a CMake project. This lesson covers configuring, generating, building, running, and troubleshooting common errors.

Building and Running CMake Projects

Learn how to organize large C++ projects in CMake using subdirectories and the `add_subdirectory()` command to create modular, maintainable builds.

CMake Project Structure and Subdirectories

Introducing CMake

Exploring CMake's programming features, caching mechanisms, and interactions with the file system

A primer on the fundamental building blocks of the CMake language: variables, string interpolation, and logging messages.

CMake Variables and Logging

Discover the CMake Cache, the mechanism for storing persistent user-configurable options, and learn how to create and manage cached variables.

The CMake Cache

Exploring CMake's command syntax and its list data type, including how to create, manipulate, and use lists in your projects.

CMake Commands, Arguments, and Lists

Transform your static build descriptions into dynamic scripts with CMake's control flow commands, if() and foreach().

CMake Conditionals and Loops

Exploring CMake's `file()` command, covering how to read, write, copy, and glob files, and how to manipulate paths.

Working with the File System

Learn to create reusable logic with CMake functions and macros, and how to organize them into modules for clean, scalable build systems.

Modularizing CMake Code

CMake Language and Fundamentals

Learn more about targets, and how their properties and links are the foundation of modern CMake

Learn to work with target properties - understanding their purpose, setting and updating them, and retrieving them when your build requires it

Target Properties

Learn about target types, and how the `PUBLIC`, `PRIVATE`, and `INTERFACE` keywords control how properties are shared.

Relationships Between Targets

Discover how CMake's `target_link_libraries()` command builds a dependency graph, and how it uses this graph to automatically manage transitive dependencies and link order.

Indirect Relationships and the Dependency Graph

Learn to use abstract target types like `INTERFACE`, `ALIAS`, and `IMPORTED` to model complex project needs, organize build properties, and integrate pre-compiled binaries.

Using `INTERFACE`, `ALIAS`, and `IMPORTED` Libraries

Adding support for user-configurable library types and an initial introduction to target installation.

Using Shared Libraries

Targets and Dependencies

Learn how to manage multiple build configurations within the same project, and how to create scripts that adapt to the environment

Learn how CMake manages different build configurations like Debug and Release, the difference between generator types, and how to apply settings conditionally using modern techniques.

Build Configurations (Debug, Release, etc.)

Learn the tools and patterns needed to write portable CMakeLists.txt files that work seamlessly across platforms and compilers

Cross-Platform Configurations

Learn to write architecture-aware CMake scripts for 32/64-bit systems and Apple's Universal Binaries (Intel/ARM).

Handling Different Architectures

Learn to build for different operating systems and architectures using CMake's cross-compilation support and toolchain files.

Cross-Compilation and Toolchain Files

Platforms and Build Configurations

Learn how to add external libraries to our build, and how to create our own packages for others to use

Learn to find and use pre-installed libraries with `find_package()`, understanding Module vs. Config mode and the power of imported targets

Finding Dependencies using `find_package()`

Learn how to make your libraries consumable by other projects using CMake by turning your build-tree into a distributable install-tree.

Creating a Consumable Package

Learn how to consume a CMake package you've installed, completing the producer-consumer cycle. We'll cover using `find_package()` and how to point CMake to your library's location

Using Installed Packages

Learn how to create self-contained, reproducible builds by fetching dependencies from source using `FetchContent()` and `ExternalProject_Add()`.

Fetching External Dependencies

Creating and Consuming Packages

Integrating the vcpkg and Conan package managers to handle external dependencies

Learn to manage C++ dependencies effortlessly with the vcpkg package manager and its seamless CMake integration using toolchain files and manifests.

Integrating CMake and vcpkg

Learn the day-to-day commands for managing dependencies with vcpkg and how to guarantee reproducible builds using baselines and version overrides

vcpkg Commands and Versioning

Combine vcpkg with CMake's cross-compilation capabilities. Learn to use triplets to target different architectures and chain-load toolchain files

Cross-Compiling with vcpkg

Discover Conan, the binary-first C++ package manager, and learn how to integrate it with CMake using profiles and lockfiles for fast, reproducible builds.

Using Conan with CMake

Learn to cross-compile C++ projects with Conan, using build and host profiles to manage dependencies for different platforms.

Cross-Compilation with Conan

Package Managers

Introducing presets, allowing us to simplify our workflow and share common configurations across our team

Learn the fundamentals of CMake Presets. This lesson introduces `CMakePresets.json` to simplify complex build commands.

CMake Presets

Learn to structure your CMake presets with inheritance and customize them for your local environment using `CMakeUserPresets.json`.

User Presets and Inheritance

Learn to make your CMake presets portable by using environment variables and conditional logic to adapt to different machine configurations.

Environment Variables and Conditional Presets

Learn how to extend the build process beyond simple compilation by integrating external tools and custom commands

Learn how to use generator expressions `$<...>` for build-time conditional logic.

Generator Expressions and Conditional Logic

Learn how to attach commands to specific points in a target's build lifecycle using `add_custom_command(TARGET)` for tasks like post-build file copying.

Integrating Tools with `add_custom_command()`

Learn to integrate code generators like Protobuf into your build process using `add_custom_command()`, creating automated file-level dependencies in CMake.

Generating Files with Protobuf and `add_custom_command()`

Custom Commands

An introduction to automating common workflow chores by creating custom targets

Learn to create standalone, non-code targets using add_custom_target() for utility tasks like code formatting and documentation generation.

Custom Targets and Build Utilities

Using the Clang-Format tool to automatically enforce a consistent coding style, and integrating it into our build using a custom CMake target

Using Clang-Format

An introduction to file sets and the `target_sources()` command, allowing us to manage our header files in a more controlled way

Using File Sets

A step-by-step guide to integrating Doxygen into your CMake build process for automated C++ documentation.

Generating Documentation with Doxygen

Custom Targets

Integrate automated tests into a CMake project using CTest, GoogleTest, and GoogleMock

Learn the fundamentals of automated testing in C++ with CTest. Create your first test suite, register tests with `add_test()`, and run them with the `ctest` command.

Automated Testing and CTest

Learn to refactor manual C++ tests into a professional test suite using the GoogleTest framework, managed by vcpkg and integrated with CTest.

Integrating GoogleTest with CMake

Learn to use a wide range of assertions, write data-driven parameterized tests, and isolate dependencies with Google Mock.

Assertions and Parameterized Tests

Learn how to isolate dependencies that our project uses, and then how to replace those dependencies at test time using Google Mock.

Dependency Injection and Mocking

Learn the standard pattern for testing application logic by refactoring it into a linkable library

Testing Executables

Move beyond individual tests to manage a full test suite. Learn to organize tests, run tests in parallel, filter by labels, and measure our code coverage

Managing a Test Suite

Automated Testing

Using static and dynamic analysis in CMake projects to automatically detect memory bugs, performance issues, and problematic code

Learn to find memory bugs at runtime by integrating AddressSanitizer (ASan) into a CMake project

Using AddressSanitizer (ASan)

Adding benchmarks to our build to measure the performance of our code, and track how it changes over time

Using Google Benchmark

Integrating Clang-Tidy to enforce good practices and find bugs before we even compile

Using Clang-Tidy

Automated Analysis

Automating the entire development lifecycle using Git for souce control, GitHub Actions for cloud builds, and CPack to create distributable packages and installers.

An introduction to Git, the version control system that underpins modern collaborative software development and automated build pipelines.

Source Control with Git

Learn how to automate your build and test process with Continuous Integration (CI) and a build server. This lesson provides a guide to creating a GitHub Actions workflow for a CMake project.

Build Servers and Continuous Integration

Learn to package your C++ projects using CMake's CPack. This lesson covers creating developer ZIP archives and professional Windows MSI installers with components.

Packaging with CPack

Learn to automate the packaging process by integrating CPack with a multi-platform GitHub Actions workflow

Packaging with GitHub Actions

Learn to automate the creation of a professional Windows installer by integrating CPack, the WiX Toolset, and a multi-platform GitHub Actions workflow.

Creating Installers with CPack and GitHub Actions

Learn to automate the release process using a GitHub Actions workflow that builds, packages, and publishes artifacts to a GitHub Release

Deployment with GitHub Releases

Continuous Integration and Packaging

If you have a basic grasp of C++ but find the build process intimidating, this course is for you. We assume you know the language, but not how to manage large projects.

Manage complex, cross-platform builds using industry-standard tools. Create scalable build systems that automate the entire development lifecycle.

This course is a comprehensive deep-dive into the entire C++ build ecosystem, centered around the power and flexibility of modern CMake. We leave no stone unturned.

Start with a foundational understanding of compilers, linkers, static vs. shared libraries, and object files.

The Full Build Pipeline

Learn every aspect of the CMake language, from variables and control flow to functions, modules, and generator expressions.

Complete CMake Language Mastery

Master the modern target-centric paradigm, including properties, usage requirements, and abstract targets.

Advanced Target Management

Explore every method for handling dependencies, from `find_package` and `FetchContent` to vcpkg and Conan, including versioning and cross-compilation.

In-Depth Dependency Management

Integrate a full suite of professional tools for testing (CTest, GoogleTest), analysis (ASan, Clang-Tidy), and packaging (CPack).

Total Workflow Automation

Build a fully automated deployment pipeline that takes your code from a Git push to a published GitHub Release with multi-platform installers.

End-to-End CI/CD and Deployment

What You'll Learn

Become a software engineer with C++.  Starting from the basics, we guide you step by step along the way

Intro to C++ Programming

If you're completely new to programming or want a thorough introduction, consider starting with our free introductory course:

New to Programming?

Managing C++ Projects Using CMake

In the last lesson, we integrated vcpkg into our CMake project. By creating a simple `vcpkg.json` manifest and pointing our toolchain file, we were able to have `find_package()` automatically download and build our dependencies.


This is just the surface of what vcpkg can do. In this lesson, we'll explore the vcpkg command-line tool itself and the manifest features that give us fine-grained control over our dependencies.


We'll learn how to manage our manifest, search for libraries, and, most importantly, lock down dependency versions to ensure our builds are perfectly reproducible every time.


## Using `vcpkg` Commands


Aside from just fetching dependencies, the `vcpkg` tool itself has a suite of commands that can be helpful for managing projects.  For example, it allows us to easy add a dependency to our manifest using a command like `vcpkg add spdlog`.


To use this effectively, we should update our system to allow us to access `vcpkg` from any directory, not just the directory in which it was installed.  We do this by adding the `vcpkg` installation location to our system's `PATH` environment variable.


### For Windows

1. In the Start Menu, search for "Edit the system environment variables" and open it.
2. In the System Properties window that appears, click the "Environment Variables..." button.
3. In the bottom section, "System variables", find the `Path` variable, select it, and click "Edit...".
4. Click "New", and paste in the full path to your vcpkg installation directory (e.g., `C:\tools\vcpkg`).
5. Click OK on all the open windows to save the changes.
6. You must **close and reopen** any open command prompts or terminals for the change to take effect.

### For macOS and Linux


The process involves editing your shell's configuration file. First, determine your shell by running `echo $SHELL`.


Then we open the appropriate configuration file in a text editor. This is typically `~/.zshrc` for zsh (the default on modern macOS) or `~/.bashrc` for bash.


Add the following line to the end of the file, replacing `~/vcpkg` with the actual path where you installed vcpkg.


```bash
export PATH="$PATH:~/vcpkg"
```


Save the file. To apply the changes, either restart your terminal or run `source ~/.zshrc` (or `source ~/.bashrc`).


### For MSYS2


The process is the same as for Linux. From within the MSYS2 terminal, edit your `~/.bashrc` file and add the line:


```javascript
export PATH="$PATH:/path/to/your/vcpkg/installation"
```


## Adding Packages


We can confirm that vcpkg has been added to our path by running the following command from any directory:


```c++
//<ti>
vcpkg --version
```


If it worked, we should see vcpkg respond with its version:


```c++
//<o>
vcpkg package management program version 2025-07-21
```


With vcpkg added to our path, we can now run `vcpkg` commands anywhere.


For example, we can quickly add a package to our project using the `vcpkg add SomePackage` command.


Let's add [tabulate](https://github.com/p-ranav/tabulate) to our project.  This is a library to make creating tables easier.  From within our project directory, we can do that using:


```c++
//<ti>
vcpkg add port tabulate
```


```c++
//<o>
Succeeded in adding ports to vcpkg.json file.
```


The "port" keyword is essentially what vcpkg calls a package definition.


Many of vcpkg's commands, including `add`, will search upwards for the closest manifest file (`vcpkg.json`) so running this from our `/build` directory or any other directory within our project will work as expected.


It will find and update the `vcpkg.json` in our project root which, if we now check, we should see `tabulate` added to the `dependencies` array.


<CodeFile path="vcpkg.json">


```json
{
  "dependencies": [
    "spdlog",
    "tabulate"//<h>
  ]
}
```


</CodeFile>


We can now find and link it in our `app/CMakeLists.txt` file in the usual way:


<CodeFile path="app/CMakeLists.txt">


```c++
#<cmake>
cmake_minimum_required(VERSION 3.16)

add_executable(GreeterApp src/main.cpp)

find_package(spdlog CONFIG REQUIRED)
find_package(tabulate CONFIG REQUIRED)#<h>

target_link_libraries(GreeterApp
  PRIVATE
  GreeterLib
  spdlog::spdlog
  tabulate::tabulate#<h>
)
```


</CodeFile>


A basic table can be created like this:


<CodeFile path="app/src/main.cpp">


```c++
#include <iostream>
#include <greeter/Greeter.h>
#include <spdlog/spdlog.h>
#include <tabulate/table.hpp> // <h>

int main() {
  spdlog::info(get_greeting());
    
  tabulate::Table Greetings;
  Greetings.format().locale("C");
  Greetings.add_row({"Language", "Greeting"});
  Greetings.add_row({"English", "Hello, World!"});
  Greetings.add_row({"German", "Hallo, Welt!"});
  Greetings.add_row({"French", "Bonjour, le Monde!"});
  std::cout << Greetings;

  return 0;
}
```


</CodeFile>


```c++
//<o>
[2025-08-14 14:49:19.095] [info] Hello from the modular greeter library!
+----------+--------------------+
| Language | Greeting           |
+----------+--------------------+
| English  | Hello, World!      |
+----------+--------------------+
| German   | Hallo, Welt!       |
+----------+--------------------+
| French   | Bonjour, le Monde! |
+----------+--------------------+
```


<Pw>


## Ensuring Repeatable Builds


We've solved the speed and setup problems, but what about reproducibility? How do we ensure every developer on the team or everyone we share our project with uses the exact same version of dependencies that we're using?


### Registry Versioning


Currently, we're not specifying what versions of `spd` and `tabulate` our project wants to use.  We're just letting vcpkg decide.


This is a problem for reproducibility.  When we or someone else rebuilds the project later, the vcpkg registry may have been updated to change what version of these libraries is should install by default.  This may, in turn, change or break the behaviour of our overall program.


However, this process of letting vcpkg decide the versions also presents an interesting opportunity to quickly implement reproducibility.  Rather than specifying the version of each individual library, we can instead specify the "version" of the vcpkg registry itself.


If someone builds our project with the same version of the registry, that means the version that vcpkg selects will be exactly the same across both builds.  To implement this, we just need to specify what version of the registry we want to use.  In vcpkg terminology, this is called the **baseline**.


### Adding a Baseline


vcpkg tracks the baseline version using a `"builtin-baseline"` value that we can add to our `vcpkg.json` manifest.  To add an initial value, we can run the following command:


```c++
//<ti>
vcpkg x-update-baseline --add-initial-baseline
```


```c++
//<o>
updated registry 'https://github.com/microsoft/vcpkg'
```


If we now look in our `vcpkg.json`, we should see this recorded:


<CodeFile path="vcpkg.json">


```c++
{
  "dependencies": [
    "spdlog",
    "tabulate"
  ],
  "builtin-baseline": "44a1e4eca5211434b5fefcc25a69bba246c3f861"
}
```


</CodeFile>


On any future build of our software, vcpkg will see this `builtin-baseline` and install the same versions of our dependencies that we have right now, even if the registry has been updated with newer versions since.


For software we're maintaining over time, we should occassionally update our baseline.  We do that by running the command again, but without the `--add-initial-baseline` argument:


```c++
//<o>
vcpkg x-update-baseline
```


On our next build, we'll then be using the most recent versions of our dependencies.  This lets us incorporate the latest changes and improvements, but in a controlled way.  That is, after updating our baseline, we should do a clean build and test that our program still works as expected with the updated versions of our dependencies.


<Aside>


### Viewing Baseline Versions


These large string values like `"44a1e..."` used in the `builtin-baselines` are unique identifiers representing changes within vcpkg's code history.


The package versions associated with the `"44a1e..."` identifier in our previous example can be seen on [this GitHub page](https://github.com/microsoft/vcpkg/blob/44a1e4eca5211434b5fefcc25a69bba246c3f861/versions/baseline.json).  To see the versions used at a different baseline, we'd replace the `"44a1e..."` component of this URL with the identifier we're interested in.


</Aside>


<Aside>


### Custom Registries


This baseline key is called `"builtin-baseline"` as it applies to the "built in" registry that vcpkg uses by default.


Advanced users can add additional registries to their configuration, thereby widening the range of packages that can be installed through vcpkg.


For example, a large organisation might maintain a private registry to make all of their internal packages easier to consume.


</Aside>


## Per-Dependency Versions


The baseline mechanism described above can do a lot of heavy lifting, but sometimes, we need to specify minimum versioning requirements for some of our dependencies.


For example, if we wanted to specify the minimum version of spdlog we use, but let the vcpkg baseline determine the tabulate version, we'd replace our simple `"spdlog"` string with a JSON object containing both the `name` and `version>=` (minimum version):


<CodeFile path="vcpkg.json">


```json
{
  "dependencies": [
    "spdlog",//<d>
    {//<h>
      "name": "spdlog",//<h>
      "version>=": "1.15.0"//<h>
    },//<h>
    "tabulate"
  ],
  "builtin-baseline": "44a1e4eca5211434b5fefcc25a69bba246c3f861"
}
```


</CodeFile>


Within the `dependencies` array, vcpkg only allows us to specify a minimum version requirement.  If we need to set a requirement at all, setting only a minimum is generally recommended, as it maximises compatibility.  However, if we really need an exact version of a library, we can use the `overrides` mechanism, which we cover next.


## Version Overrides


If we need to specify the exact version of a package we want to use, we can add it to an `"overrides"` section of our manifest.  Below, we lock spdlog to exactly version 1.15.1:


<CodeFile path="vcpkg.json">


```c++
{
  "dependencies": [
    "spdlog",
    "tabulate"
  ],
  "overrides": [{//<h>
    "name": "spdlog",//<h>
    "version": "1.15.1"//<h>
  }],//<h>
  "builtin-baseline": "44a1e4eca5211434b5fefcc25a69bba246c3f861"
}
```


</CodeFile>


We should be cautious here, as this will also override any **transitive** use of spdlog through other dependencies.  That is, if one of our other dependencies were also using spdlog, we'd override their version too, which can have unintended consequences.


After running a build, we can see information about the packages installed, including the versions, by looking in the `/vcpkg_installed/vcpkg/status` file within our build directory:


<CodeFile path="build/vcpkg_installed/vcpkg/status">


```yaml
Package: fmt
Version: 11.2.0
...

Package: spdlog
Version: 1.15.1
Depends: fmt
...

Package: tabulate
Version: 1.5
...
```


</CodeFile>


### Overriding Transitive Dependencies


The `fmt` library in this list is an example of a **transitive dependency**.  We don't require it directly, but `spdlog` does, so it gets downloaded and compiled it so `spdlog` can link against it.


Even though it's not our direct dependency, we can still override the version that gets used in our build:


<CodeFile path="vcpkg.json">


```c++
{
  "dependencies": [
    "spdlog",
    "tabulate"
  ],
  "overrides": [{//<h>
    "name": "fmt",//<h>
    "version": "11.0.2"//<h>
  }],//<h>
  "builtin-baseline": "44a1e4eca5211434b5fefcc25a69bba246c3f861"
}
```


</CodeFile>


After running a build, we can confirm the change reflected in the `status` file:


<CodeFile path="build/vcpkg_installed/vcpkg/status">


```yaml
Package: fmt
Version: 11.0.2
...
```


</CodeFile>


One of the main use cases for this is to deal with security vulnerabilities or other major issues found in a package that we're indirectly depending on.


The authors of the `fmt` library may have released a new version to fix the issue, but we may not want to update our entire baseline right now, so we instead override just the problematic version.


Overrides should be used sparingly, but they let us make small, targetted changes like this when the need arises.  They should also be temporary - when an override is no longer needed, we should delete it from our manifest.


## Summary


In this lesson, we moved beyond basic vcpkg integration and learned how to manage our dependencies with precision.

- **vcpkg Commands**: The vcpkg executable is a useful tool in its own right. We learned how to add it to our system PATH and use commands like `vcpkg add` to manage our manifest file.
- **Reproducibility with Baselines**: By adding a `"builtin-baseline"` to our `vcpkg.json`, we lock the vcpkg registry to a specific commit. This guarantees that anyone building our project will get the exact same versions of all dependencies.
- **Versioning Control**: We saw how to specify a minimum version for a dependency directly in the manifest.
- **Overrides for Pinning**: For ultimate control, the `"overrides"` feature allows us to pin the exact version of any dependency, including transitive ones. This useful for working around issues in specific library versions.

<Preview>


### Cross-Compilation with vcpkg


We've mastered dependency management for our native platform, locking down versions for reproducible builds.


But what happens when we need to cross-compile for a different architecture or operating system? How does vcpkg handle building dependencies for, say, a 32-bit ARM target when we're on a 64-bit x86 host? And how do we manage the `CMAKE_TOOLCHAIN_FILE` variable, which is needed by both vcpkg and our cross-compiler?


In the next lesson, we will learn the solutions to these problems. We'll learn about **triplets**, which tell vcpkg what platform to build for, and the concept of **chain loading**, which lets us combine our cross-compilation setup with vcpkg's dependency management.


</Preview>


</Pw>

Vendoring and Fetching Dependencies

Package Managers Integration (Conan)

vcpkg Homepage

vcpkg: A C++ package manager for Windows, Linux, and macOS

Manifest mode

CMake Toolchains

vcpkg: The C++ Library Manager for Everyone - Robert Schumacher & Augustin Popa

vcpkg GitHub Repository

This advanced vcpkg tutorial teaches you how to ensure reproducible C++ builds with CMake. Learn to use the vcpkg CLI, lock dependency versions with a `builtin-baseline`, and pin specific packages with `overrides` in your `vcpkg.json`

vcpkg Commands and Versioning

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

Managing C++ Projects Using CMake