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 learned about variables in CMake. We saw that they are the primary way we storing and reuse information, like a project's version number or a file path. However, these "normal" variables have a limitation: they are _**transient**_. Every time you run `cmake` to configure your project, they are reset and recalculated from scratch.


This is usually what you want, but what about configuration that should persist? What if a developer wants to enable a specific feature, like building with tests enabled, and have that choice _remembered_ for all future builds? Re-typing a command-line flag every single time would be incredibly annoying.


This is where the **CMake Cache** comes in. The cache is CMake's memory. It's a special set of variables that are stored on disk and persist between runs, allowing you to create truly configurable projects.


## What is the CMake Cache?


When you successfully run the configure command (`cmake ..`), you may have noticed that CMake creates a file named `CMakeCache.txt` inside your build directory. This file is a simple key-value store that saves the values of cached variables.


Think of it like this:

- **Normal variables** are like local variables inside a function. Once the function (the `cmake` run) finishes, they're gone.
- **Cached variables** are like a `.ini` or `.json` configuration file. The program writes to it once, and then reads from it on every subsequent startup.

The cache's primary purpose is to store information that is either:

1. **Expensive to compute and rarely changes**: Things like the path to the C++ compiler or the results of system checks. CMake figures these out once and then stores them in the cache so it doesn't have to re-do the work every time, making our builds faster.
2. **User-configurable options**: Settings that a user of your project might want to change, like `BUILD_TESTS` or `USE_CUSTOM_FEATURE`.

If you open `CMakeCache.txt` (though you should rarely edit it by hand), you'll see something like this:


```c++
# ... lots of internal variables ...

//The name of the CXX compiler
CMAKE_CXX_COMPILER:FILEPATH=D:/msys64/ucrt64/bin/c++.exe

//The CXX compiler identification
CMAKE_CXX_COMPILER_ID:STRING=GNU

# ... more variables ...
```


Each entry has a `KEY:TYPE=VALUE` format, along with a comment that serves as documentation. This file is the physical manifestation of CMake's memory.


## Creating Cached Variables


So how do we create a variable that gets saved to this file? We use a special form of the `set()` command.


### Using `set()` with the `CACHE` keyword


To create a cached variable, you provide the `CACHE` keyword to the `set()` command, along with a type and a documentation string.  The syntax looks like this:


```c++
#<cmake>
set(name value CACHE type "description")
```


Let's break down the arguments:

- `name`: The name of the variable. By convention, user-configurable options are often in `ALL_CAPS`.
- `value`: The **default value** for the variable. This is only used the _first time_ CMake encounters this command, which we'll explain later in the lesson.
- `CACHE`: The magic keyword that tells CMake this is a cached variable.
- `type`: A type hint specifying what type of variable this is, which can be useful for GUI tools like `cmake-gui`. For example, if we set this to `BOOL`, which is the most common type in real-world use cases, a GUI might render this option as an ON/OFF checkbox.  Other options include `STRING` for arbitrary text, `PATH` for a directory picker, `FILEPATH` for a file picker, and `INTERNAL` for a private variable that should be hidden from GUI tools.
- `description`: A short, helpful description of what the variable is for.  This is sometimes referred to as a _**docstring**_ (documentation string)

A cached variable that configures whether CMake creates a build of our software that says goodbye to the user might look something like this, where some optional white space has been added:


```c++
set(
  SAY_GOODBYE OFF CACHE BOOL
  "Should the program say goodbye before exiting"
)
```


We'll see how to react to this option later in the lesson.


### The `option()` Command


For boolean options (ON/OFF switches), there's a more convenient shorthand command called `option()`:


```c++
option(name docstring value)
```


Using `option()` is preferred for boolean flags as it's more concise and clearly expresses your intent to create a toggleable feature.


Rewriting our `SAY_GOODBYE` variable to use `option()` instead of `set()` would look like this:


```c++
option(
  SAY_GOODBYE
  "Should the program say goodbye before exiting"
  OFF
)
```


<Pw>


## A Practical Example


Let's update our `GreeterApp` component's `CMakeLists.txt` file (in the `/app` directory) with this `SAY_GOODBYE` option.  If this variable is set to `ON`, we'll have CMake define a preprocessor macro, and we'll update our source code to check for it.


To set a preprocessor definition for a target, we use the `target_compile_definitions()` command.  We want to do this only if `SAY_GOODBYE` is enabled, so we'll place this command in an `if()` block.


We'll explain both `target_compile_definitions()` and `if()` in detail later in the course, but a basic example would look like this:


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


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

option(#<h>
  SAY_GOODBYE#<h>
  "Should the program say goodbye before exiting"#<h>
  OFF#<h>
)#<h>

add_executable(GreeterApp src/main.cpp)
target_compile_features(GreeterApp PUBLIC cxx_std_20)
target_link_libraries(GreeterApp GreeterLib)

if(SAY_GOODBYE) #<h>
  target_compile_definitions(GreeterApp PUBLIC SAY_GOODBYE) #<h>
endif() #<h>
```


</CodeFile>


Finally, let's modify our C++ code to react to this definition:


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


```c++
#include <iostream>
#include <greeter/Greeter.h>

int main() {
  std::cout << get_greeting();
#ifdef SAY_GOODBYE//<h>
  std::cout << "\nGoodbye";//<h>
#endif//<h>
  return 0;
}
```


</CodeFile>


Our project is now configurable! By default, nothing has changed. If we build and run it, we'll just get the "Hello" message. But now we have a knob we can turn to add additional behavior.


### Logging Updates Using `message()`


Remember, we can liberally scatter `message()` commands through our `CMakeLists.txt` files to keep track of what's going on, and to help others do the same.


If we think some update is relatively important, we might use the `STATUS` mode:


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


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

option(
  SAY_GOODBYE
  "Should the program say goodbye before exiting"
  OFF
)

add_executable(GreeterApp src/main.cpp)
target_compile_features(GreeterApp PUBLIC cxx_std_20)
target_link_libraries(GreeterApp GreeterLib)

if(SAY_GOODBYE)
  message(STATUS "Defining SAY_GOODBYE") #<h>
  target_compile_definitions(GreeterApp PUBLIC SAY_GOODBYE)
endif()
```


</CodeFile>


If something is less important, we can use the `VERBOSE`, `DEBUG`, or `TRACE` modes to hide it by default, but still make it available for anyone who wants to increase their `--log-level`.


## Modifying the Cache


There are two primary ways a user can change the value of a cached variable: from the command line, or using a GUI tool.


### Command-Line with `-D`


The `-D` flag allows you to define a cached variable's value during the configure step. The flag sets a variable, and does not care if it already has a value.


Let's try building our project with our new option enabled.  As usual, we'll run our command from the `/build` directory:


```c++
//<ti>
cmake -DSAY_GOODBYE=ON ..
```


When you run this, CMake configures the project. It sees our `option()` command, but because we provided a value for `SAY_GOODBYE` on the command line, it uses `ON` instead of the default `OFF`. It then saves `SAY_GOODBYE=ON` into the `CMakeCache.txt` file.  Our output will look something like this:


```c++
//<o>
-- Configuring Greeter Version: 1.0
-- Defining SAY_GOODBYE
-- Configuring done (0.8s)
-- Generating done (0.1s)
-- Build files have been written to: D:/Projects/cmake/build
```


Now, let's build our application:


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


And let's run it it from the `./app` directory, remembering to add `.exe` if you're on Windows:


```c++
//<ti>
./app/GreeterApp
```


```c++
//<o>
Hello from the modular Greeter library!
Goodbye
```


Success! Our configuration change worked.


### Updating Cached Values


Remember, with a cached variable, _**the choice is persistent**_. If you now run the configure command again _without_ the `-D` flag, CMake will read the existing `CMakeCache.txt`, see that `SAY_GOODBYE` is already set to `ON`, and continue to use that value:


```c++
//<ti>
cmake ..
```


If we've added a `message()` command when `SAY_GOODBYE` is `ON`, we'll see that reflected in our output:


```c++
//<o>
-- Configuring Greeter Version: 1.0
-- Defining SAY_GOODBYE
-- Configuring done (0.1s)
-- Generating done (0.1s)
-- Build files have been written to: D:/Projects/cmake/build
```


Alternatively, we can just build our program and see that we're still using the cached value:


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


```c++
//<ti>
./app/GreeterApp
```


```c++
//<o>
Hello from the modular Greeter library!
Goodbye
```


To change a cached value, you simply run the configure step again, using the `-D` flag as before to provide a new value:


```c++
//<ti>
cmake -DSAY_GOODBYE=OFF ..
```


```c++
//<o>
-- Configuring Greeter Version: 1.0
-- Configuring done (0.1s)
-- Generating done (0.1s)
-- Build files have been written to: D:/Projects/cmake/build
```


### Deleting Cached Values


We can unset a specific variable from the cache, causing it to adopt its default value, using the `-U` option:


```c++
//<ti>
cmake -USAY_GOODBYE ..
```


We can also remove all cached variables by manually deleting the `CMakeCache.txt` file or, if you have **CMake 3.24 or later** installed, by using the `--fresh` option:


```c++
//<ti>
cmake --fresh ..
```


You may notice this option takes a little longer to run.  This is because CMake has to reexamine our environment more thoroughly to recalculate **all** of the previously cached values, such as what compilers we have installed and where they are located.


### Using a GUI (`cmake-gui`)


The `-D` flag is great for scripting, but it's not very user-friendly. This is where GUI tools shine. CMake comes with such a GUI tool by default.


If we run cmake-gui and open our `/build` directory within the tool, we'll see our `SAY_GOODBYE` option presented visually, alongside some others that are provided by default.  Hovering over the option will also display the description we set as a tooltip:


<Img hasTransparency file="cmake-gui-cache.png" alt="Screenshot showing the cmake-gui configuration options" width="808" height="499" blurHash="L5RW3lITD%xu?YIoIUWB~NWCRjxu" />


A less technical user can now get a visual overview of the options they have, and simply check or uncheck the box.  They can create a build without being familiar with the command line, or even familiar with CMake.


This is the power of adding types and docstrings to your variables: you are enabling GUI interfaces to be created for your build.


## The Cache Precedence Rule and `FORCE`


There is a fundamental rule that is often misunderstood about the cache:


_**Once a variable is in the cache, its value will not be changed by a normal**_ _**`set()`**_ _**or**_ _**`option()`**_ _**command in the**_ _**`CMakeLists.txt`**_ _**file.**_


The cached value always takes precedence over the default value in the script. This is what makes the user's choice take precedence over the default values we may have set in the `CMakeLists.txt` file.


The `-D` flag is one way to override the cached value.  But what if you, the project author, need to programmatically override a cached value? You can do this by adding the `FORCE` keyword to your `set()` command.


```c++
#<cmake>
set(MY_VAR "New Value" CACHE STRING "Some docs" FORCE)
```


This command will overwrite whatever value for `MY_VAR` is currently in the cache.


### Use `FORCE` with Caution


Using `FORCE` is generally considered bad practice for user-facing options. It's a "hammer" that stomps on the user's configuration without their knowledge, which can be incredibly confusing. Imagine explicitly setting an option with `-D` or in a GUI tool, only to have your choice ignored because the `CMakeLists.txt` silently changes it back.


`FORCE` should be reserved for situations where the build script _**must**_ enforce a value in a specific situation, perhaps based on the detected operating system or other internal logic.


Even then it should be used sparingly and be well-documented, perhaps with `message()` commands using the `WARNING` mode.  It might look something like this:


```c++
#<cmake>
set(say_goodbye_doc "Should the program say goodbye")
option(SAY_GOODBYE "${say_goodbye_doc}" OFF)

if(WIN32 AND SAY_GOODBYE)
  message(
    WARNING
    "SAY_GOODBYE not supported on Windows - forcing it OFF"
  )
  set(SAY_GOODBYE OFF CACHE BOOL "${say_goodbye_doc}" FORCE)
endif()
```


Just throwing a `FATAL_ERROR` on an invalid configuration is usually more appropriate than forcing a different value than what was requested:


```c++
#<cmake>
if(WIN32 AND SAY_GOODBYE)
  message(
    FATAL_ERROR
    "SAY_GOODBYE not supported on Windows"
  )
endif()
```


```c++
//<ti>
cmake -DSAY_GOODBYE=ON ..
```


```c++
//<o>
-- Configuring Greeter Version: 1.0
CMake Error at app/CMakeLists.txt:17 (message):
  SAY_GOODBYE not supported on Windows

-- Configuring incomplete, errors occurred!
```


## Summary


The CMake Cache is the mechanism that elevates CMake from a simple script runner to a powerful, configurable build framework. It provides the memory that makes user choices stick.

- **The Cache File**: `CMakeCache.txt` is a file in your build directory that stores persistent key-value pairs.
- **Creating Cached Variables**: Use `set(var val CACHE type "doc")` for general variables, and the `option(var "doc" val)` shorthand for boolean ON/OFF toggles.
- **Persistence**: Once a variable is in the cache, its value is used for all subsequent runs, overriding the defaults in your `CMakeLists.txt`.
- **User Configuration**: Users can change cached values from the command line (with `-D`) or with a GUI like cmake-gui.  GUI tools can use the type and docstring information you provide to create a user-friendly interface.
- **Forcing a Value**: The `FORCE` keyword allows a script to override a cached value, but it should be used with great care.

You now understand the two fundamental types of variables in CMake: normal variables for script logic and cached variables for persistent configuration.


<Preview>


### Handling Lists of Values


So far, all our variables have held a single string value. But what about a list of source files, or a list of compiler flags? CMake has a specific way of handling these collections.


In the next lesson, we will explore CMake's command syntax in more detail and learn about its list data type, a simple feature for managing collections of strings.


</Preview>


</Pw>

Fixed the Deleting Cached Variables section calling the cache `CMakeLists.txt` instead of `CMakeCache.txt`

Fixed mismatched variable name between code example and explanation in the Modifying Cache Variables section

`set()` Command Documentation (CACHE)

`option()` Command Documentation

What's the CMake syntax to set and use variables?

The Ultimate CMake / C++ Quick Start

A comprehensive guide to the CMake Cache. Learn what CMakeCache.txt is, why it's essential for persistent configuration, and how to use set(CACHE...) and option() to create user-configurable variables for your projects.

The CMake Cache

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

Managing C++ Projects Using CMake