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

Throughout the last few chapters, our build commands have been getting progressively more complex. We've added toolchain files for package managers, specified build types, and configured cross-compilation.


This has led to a new problem: our command-line invocations have become long, hard to remember, and difficult to share with others using our project who may find them useful.


This is where **CMake Presets** come in. Presets are a modern, standardized way to define and share common build configurations in a simple JSON file. They allow you to replace a long, error-prone command with a single, memorable name.


In this lesson, we'll learn the fundamentals of presets. We'll start by encapsulating a complex command into our first **configure preset**, then add a corresponding build preset, and finally understand the distinction between shared team presets and personal user presets.


In these examples, we'll use our vcpkg project from the previous chapter.  The code is provided below if you want to follow along.  Note that the `include()` command in the toolchain file (highlighted) may need updated to point to your vcpkg location.  We'll learn how to make this portable soon.


<CodeViewer>


<CodeFile path="CMakeLists.txt">


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

project(Greeter)

add_subdirectory(app)
```


</CodeFile>


<CodeFile path="vcpkg.json">


```c++
{
  "dependencies": ["spdlog"]
}
```


</CodeFile>


<CodeFile path="toolchains/mingw-windows-x64.cmake" defaultOpen>


```c++
#<cmake>
# 1. Set the target system
set(CMAKE_SYSTEM_NAME Windows)
set(CMAKE_SYSTEM_PROCESSOR x86_64)

# 2. Specify the cross-compilers
set(CMAKE_C_COMPILER x86_64-w64-mingw32-gcc)
set(CMAKE_C_FLAGS_INIT "-static -static-libgcc")

set(CMAKE_CXX_COMPILER x86_64-w64-mingw32-g++)
set(CMAKE_CXX_FLAGS_INIT
  "-static -static-libgcc -static-libstdc++")
set(CMAKE_EXE_LINKER_FLAGS_INIT
  "-static-libgcc -static-libstdc++")

# 3. Configure search for external dependencies
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

set(MINGW TRUE)
set(VCPKG_TARGET_TRIPLET x64-mingw-static)

# Update me to point to the vcpkg install location
include("~/vcpkg/scripts/buildsystems/vcpkg.cmake")#<w>
```


</CodeFile>


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


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

add_executable(GreeterApp src/main.cpp)
find_package(spdlog CONFIG REQUIRED)
target_link_libraries(GreeterApp
  spdlog::spdlog#<h>
)
```


</CodeFile>


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


```c++
#include <windows.h>
#include <spdlog/spdlog.h>
#include <spdlog/sinks/basic_file_sink.h>

int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int) {
  auto logger{spdlog::basic_logger_mt(
    "file_logger", "log.txt"
  )};
  logger->info("Program started");

  MessageBox(
    nullptr,
    "I was cross-compiled from a Mac!",
    "Hello Windows",
    MB_OK
  );
  
  logger->info("Program shut down");
  
  // Flush logs to ensure they're written
  spdlog::shutdown();
  
  return 0;
}
```


</CodeFile>


</CodeViewer>


## Preset Version Requirements


Support for presets were first introduced in version 3.19 of CMake, and were expanded in subsequent versions.  Later in the chapter, we'll use features added in 3.21 so, if you want to follow along, having at least that version is recommended.


Remember, you can check the installed `cmake` version using the command:


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


Using a recent addition to the `cmake` executable doesn't necessarily require us to update the `cmake_minimum_requirements()` for our project.  Someone on an older version could still use our project without using our presets.


However, if our project is designed around the use of presets, and our documentation recommends using them, bumping the `cmake_minimum_required()` version is a reasonable choice anyway.  This signals to users that a more modern version of CMake is expected in order to use the project as designed.


<CodeFile path="CMakeLists.txt" status="Updated">


```c++
#<cmake>
cmake_minimum_required(VERSION 3.21) #<h>
project(Greeter)

// ...
```


</CodeFile>


## The Command-Line Chore


Let's revisit the command we used to cross-compile our `Greeter` application for Windows from a macOS or Linux host. It required setting the source and build directories, the toolchain file, and the build type.


For example, if our terminal was in our project root, and we wanted to configure a vcpkg project in `/build/windows-debug`, our command to provide all of the required arguments might look like this:


```c++
//<ti>
cmake -S . -B ./build/windows-debug \                      
  -DCMAKE_TOOLCHAIN_FILE=./toolchains/mingw-windows-x64.cmake \
  -DCMAKE_BUILD_TYPE=Debug
```


And after that, we still need to repeat the correct build directory for the build command:


```c++
//<ti>
cmake --build ./build/windows-debug
```


This is a lot to type correctly every time. If a new developer joins the team, you have to document this command precisely. If you need to change a flag, you have to tell everyone to update their personal scripts.


## Creating a Configure Preset


`CMakePresets.json` is the solution. It's a file you create in the root of your project that lets you give names to these complex configurations.


Let's create this file and define our first preset to encapsulate the command above.


<CodeFile path="CMakePresets.json" status="New">


```json
{
  "version": 3,
  "configurePresets": [{
    "name": "windows-x64-debug",
    "displayName": "Windows x64 Debug",
    "description": "Build for 64-bit Windows with MinGW (Debug)",
    "binaryDir": "${sourceDir}/build/windows-x64-debug",
    "cacheVariables": {
      "CMAKE_BUILD_TYPE": "Debug",
      "CMAKE_TOOLCHAIN_FILE": "${sourceDir}/toolchains/mingw-windows-x64.cmake"
    }
  }]
}
```


</CodeFile>


Let's break down this JSON file:

- `"version"`: The schema version for the presets file. CMake adds support for new keys and features in presets over time.  Version `3` is a relatively common baseline and is supported by CMake versions 3.21 and later.
- `"configurePresets"`: An array containing one or more configure preset objects.
- `"name"`: The unique, machine-readable ID for the preset. This is what you'll use on the command line to declare that you want to use this preset. It's best to use a simple, consistent naming scheme like `os-arch-config`.
- `"displayName"` and `"description"`: Human-readable strings that GUI tools such as an IDE can use to present the preset in a friendly way.
- `"binaryDir"`: The output directory for the build.  This corresponds to the `-B` argument we'd pass on the command line. The `${sourceDir}` variable is automatically provided by CMake and points to the directory containing the `CMakePresets.json` file.
- `"cacheVariables"`: An object containing key-value pairs that will be passed as `-D` arguments to the `cmake` command. This is where we can set things like `CMAKE_BUILD_TYPE` and `CMAKE_TOOLCHAIN_FILE`.

### Listing Presets


We can ask CMake to list all of the available presets using the following command:


```c++
//<ti>
cmake --list-presets
```


The output should list our new preset as an option:


```c++
//<o>
Available configure presets:
  "windows-x64-debug" - Windows x64 Debug
```


<Pw>


## Using Presets


With this file in our project root, our long, complex configure command is now replaced with a simple, memorable one:


```c++
//<ti>
cmake --preset=windows-x64-debug
```


CMake will read `CMakePresets.json`, find the preset named "windows-x64-debug", and apply all the settings defined within it.


With that one command, we should now see our project configured in the `/build/windows-x64-debug` directory, just like our preset requested.


### Overriding Preset Values


If a preset isn't defined exactly how we want, we can still override its settings on the command line.


For example, we could use all the preset values, but override the preset-defined `binaryDir` of `/build/windows-x64-debug` to instead use `./output`:


```c++
//<ti>
cmake --preset=windows-x64-debug -B "./output"
```


CMake allows us to save personal preferences like this in a `CMakeUserPresets.json` file, which doesn't interfere with the configurations shared among the wider team in the `CMakePresets.json` file.  We cover user presets in the next lesson.


## Adding Build Presets


Simplifying the configure step is great, but we can create presets for the build step too.  This lets us create a complete, named workflow from start to finish.


Let's add a `buildPresets` section to our file:


<CodeFile path="CMakePresets.json" status="Updated">


```json
{
  "version": 3,
  "configurePresets": [{
    "name": "windows-x64-debug",
    "displayName": "Windows x64 Debug",
    "description": "Build for 64-bit Windows with MinGW (Debug)",
    "binaryDir": "${sourceDir}/build/windows-x64-debug",
    "cacheVariables": {
      "CMAKE_BUILD_TYPE": "Debug",
      "CMAKE_TOOLCHAIN_FILE": "${sourceDir}/toolchains/mingw-windows-x64.cmake"
    }
  }],
  "buildPresets": [{//<h>
    "name": "windows-x64-debug",//<h>
    "displayName": "Build Windows x64 (Debug)",//<h>
    "configurePreset": "windows-x64-debug",//<h>
    "configuration": "Debug"//<h>
  }]//<h>
}
```


</CodeFile>


In this example, our four values are:

- `"name"`: The name of the build preset, which we'll use to identify it on the command line. It's a common convention to give the build preset the same name as the configure preset it's associated with.
- `"displayName"`: As with configure presets, we can give our build presets a friendly name that can be displayed on GUI tools.
- `"configurePreset"`: This is the crucial key. It links this build preset to a specific configure preset. When you use this build preset, CMake knows it corresponds to the configuration done by `windows-x64-debug`.
- `"configuration"`: If we're using a multi-config generator, this key will set the build type that our preset uses.  We have a section below explaining this value in more detail.

Now, we can also complete the build step from the project root, using our named preset:


```c++
//<ti>
cmake --build --preset=windows-x64-debug
```


In this case, the build preset isn't quite as useful as the configure preset.  The only benefit is that we no longer need to provide the build directory (`./build/windows-x64-debug`) because that was already set in the `configurePreset` that our build preset links to.


However, as we'll see later, the commands needed to execute build steps can also get quite complex.  But with our new knowledge of build presets, rather than those commands needing to be typed, we can just add the options to our `CMakePresets.json` collection, making them easier to use and share.


<Aside>


### Using `CMAKE_BUILD_TYPE` vs `configuration`


Remember, CMake supports two different <InlineLessonPromo url="cmake/cmake-build-configurations" title="Build Configurations (Debug, Release, etc.)" description="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.">types of build systems</InlineLessonPromo>.


With a **single-config generator** like Ninja, the files generated in our `binaryDir` are dedicated to that single build type.  That type is determined during the **configuration step**, using the `CMAKE_BUILD_TYPE` variable.


```c++
//<o>
cmake .. -DCMAKE_BUILD_TYPE=Debug
```


The build artifacts created for a **multi-config generator** like Visual Studio can support multiple build types.  The type we want to use for any given build is set during the **build step** via the `config` argument:


```c++
//<o>
cmake --build . --config Debug
```


By adding both `CMAKE_BUILD_TYPE` to our configuration preset and `configuration` to our related build preset, our chain can maintain consistency across generators of either type.


If we want our preset to be associated with a specific generator, we can set that using the `generator` key:


```c++
{
  "version": 3,
  "configurePresets": [{
    "name": "ninja-preset",
    "generator": "Ninja",//<h>
    "binaryDir": "${sourceDir}/build/debug"
    "cacheVariables": {
      "CMAKE_BUILD_TYPE": "Debug"
    }
  }],
  "buildPresets": [{
    "name": "ninja-preset",
    "configurePreset": "ninja-preset",
    "configuration": "Debug"//<d>
  }]
}
```


Any build preset linked to this configure preset (via `"configurePreset": "ninja-preset"`) doesn't need to set a `configuration` value.  The Ninja generator only supports single build type, and that would already have been set in the configuration preset.


</Aside>


<Aside>


### The `toolchainFile` Key


Needing to set the `CMAKE_TOOLCHAIN_FILE` cache variable is so common that the preset schema from version `3` onwards provides a shortcut for this.  We can instead set a top-level `toolchainFile` value if preferred:


```c++
{
  "version": 3,
  "configurePresets": [{
    "name": "some-preset",
    "toolchainFile"://<h>
      "${sourceDir}/toolchains/some-toolchain.cmake"//<h>
    "cacheVariables": {//<d>
      "CMAKE_TOOLCHAIN_FILE"://<d>
        "${sourceDir}/toolchains/some-toolchain.cmake"//<d>
    }//<d>
  }]
}
```


</Aside>


## Summary


CMake Presets are a feature that improves the usability of the CMake command line, turning complex, error-prone commands into simple, named workflows.

- **The Problem**: Long `cmake` command lines with many arguments are hard to remember, type, and share.
- **The Solution**: Define configurations in a `CMakePresets.json` file.
- **Configure Presets**: Define values like the generator, build directory, and cache variables for the `cmake` command.
- **Build Presets**: Link to a configure preset to define a corresponding workflow for the `cmake --build` command.

<Preview>


### User Presets and Inheritance


We've seen how to create basic, standalone presets. But as a project grows, with multiple operating systems, compilers, and build types, a flat list of presets can become repetitive and difficult to maintain.


In the next lesson, we will learn how to structure our presets using **inheritance**. We'll create hidden "base" presets to define common settings and then layer them together to build up complex configurations without duplicating code. This is the key to creating a truly scalable and maintainable preset architecture.


</Preview>


</Pw>

Added footnotes on single vs multi config presets and the `toolchainFile` key

User Presets and Customization

Configure and build with CMake Presets in Visual Studio

The Power of CMake Presets

A Tour of CMake 3.20 - Bill Hoffman

CMake Presets in CLion

What's the difference between CMakePresets.json and CMakeSettings.json?

A beginner's guide to CMakePresets.json. Learn how to create configure and build presets to replace long, error-prone command lines, and understand the difference between shared (CMakePresets.json) and user (CMakeUserPresets.json) configurations.

Introduction to CMake Presets: Simplify Your Build Commands

Using `CMAKE_BUILD_TYPE` vs `configuration`

CMake Presets

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

Managing C++ Projects Using CMake