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

So far, we've treated CMake as a tool where we call a few commands like `add_library()` and `project()`. While this is true, it's also an incomplete picture. CMake isn't just a list of commands; it's a full-fledged scripting language with its own syntax, rules, and idioms.


We've already had a glimpse of this with `${PROJECT_SOURCE_DIR}`, which looks suspiciously like a variable. To move beyond simple projects and write flexible and maintainable build scripts, we need to understand the grammar of the CMake language.


In this lesson, we'll introduce three important building blocks: variables, string interpolation, and logging.


## Creating Variables


At its heart, CMake is a language for manipulating strings. The primary way we store and manage these strings is with variables. A variable can hold a file path, a compiler flag, a list of source files, or just a simple piece of text.


### Setting Variables with `set()`


The workhorse command for creating and modifying variables is `set()`. Its most basic form is this:


```c++
set(VARIABLE_NAME "Value")
```


Let's add a version number to our project's `CMakeLists.txt`:


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


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

set(GREETER_VERSION "1.0")#<h>

project(Greeter)

add_subdirectory(greeter)
add_subdirectory(app)
```


</CodeFile>


Here, we created a variable named `GREETER_VERSION` and assigned it the string value `"1.0"`.


<Aside>


### Everything is a String


It's helpful to remember that, at a fundamental level, _**everything in CMake is a string**_. When you write `set(MY_NUMBER 123)`, CMake stores the string `"123"`, not a numeric type.


When a command needs a number, it will try to interpret the string as one. This simplifies the language but can sometimes lead to surprising behavior if you're used to strongly-typed languages.


</Aside>


### Updating Variables


We can update the value of an existing variable by using `set()` again.  We pass the same name as the first argument, and the new value as the second argument:


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

set(GREETER_VERSION "1.0")
project(Greeter)

set(BUILD_STEP "1")#<h>
add_subdirectory(greeter)

set(BUILD_STEP "2")#<h>
add_subdirectory(app)
```


### Unsetting Variables with `unset()`


We can unset a variable by using `set()` without a second argument or, more explicitly, by using `unset()`:


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

set(GREETER_VERSION "1.0")

project(Greeter)

set(BUILD_STEP "1")
add_subdirectory(greeter)

set(BUILD_STEP "2")
add_subdirectory(app)

# Unset the variable:
set(BUILD_STEP)#<h>

# Alternatively:
unset(BUILD_STEP)#<h>
```


## Dereferencing Variables


To use the value stored in a variable, you "dereference" it using the `${VARIABLE_NAME}` syntax. CMake will replace this placeholder with the variable's string content before executing the command.


For example, the `project()` command we introduced earlier allows us to attach optional metadata to our project, such as a description, a website URL, and a version number.


Each piece of metadata is provided as two arguments, in the form of a key-value pair.  An example is provided below, where we've also added some optional white space and used our new `GREETER_VERSION` variable:


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

set(GREETER_VERSION "1.0")

project(Greeter)#<d>
project(#<h>
  Greeter#<h>
  VERSION ${GREETER_VERSION}#<h>
  HOMEPAGE_URL "https://www.studyplan.dev"#<h>
  DESCRIPTION "A program that says hello to people"#<h>
)#<h>

add_subdirectory(greeter)
add_subdirectory(app)
```


<Pw>


## Variable Scope


Where you `set()` a variable determines where it can be used.  When you call `add_subdirectory(greeter)`, CMake creates a new scope.  CMake's default scoping behaviour is generally going to be recognisable for those familiar with C++, or most other programming languages:

- **Variables flow down**: Variables set in a parent scope (like the root `CMakeLists.txt`) are visible in all child scopes (like `greeter/CMakeLists.txt`) that are processed _after_ the `set()` command.
- **Variables do not flow up**: Variables set in a child scope are _**not**_ visible in the parent scope.

Let's demonstrate this with our modular project.


First, let's update our root `CMakeLists.txt` to print our version variable. We'll introduce the `message()` command here, which is CMake's equivalent of C++ expressions that might involve `std::cout`, `printf()`, or `std::print()`:


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


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

set(GREETER_VERSION "1.0")

project(
  Greeter
  VERSION ${GREETER_VERSION}
  HOMEPAGE_URL "https://www.studyplan.dev"
  DESCRIPTION "A program that says hello to people"
)

message("Root scope version: ${GREETER_VERSION}")#<h>

add_subdirectory(greeter)
add_subdirectory(app)
```


</CodeFile>


Now, let's try to access that variable from within the library's `CMakeLists.txt`:


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


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

add_library(GreeterLib src/Greeter.cpp)
target_include_directories(GreeterLib PUBLIC
  ${CMAKE_CURRENT_SOURCE_DIR}/include
)
target_compile_features(GreeterLib PUBLIC cxx_std_20)

message("Library scope version: ${GREETER_VERSION}")#<h>
```


</CodeFile>


If we configure our project now (by running `cmake ..` from the `build` directory), we'll see both messages print correctly, proving that the variable flowed down into the subdirectory:


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


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


Now let's try the reverse. Let's set a variable inside the library's scope and try to access it from the application's scope.


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


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

add_library(GreeterLib src/Greeter.cpp)
target_include_directories(GreeterLib PUBLIC
  ${CMAKE_CURRENT_SOURCE_DIR}/include
)
target_compile_features(GreeterLib PUBLIC cxx_std_20)

set(LIBRARY_MESSAGE "This is the GreeterLib") #<h>
```


</CodeFile>


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


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

set(GREETER_VERSION "1.0")

project(
  Greeter
  VERSION ${GREETER_VERSION}
  HOMEPAGE_URL "https://www.studyplan.dev"
  DESCRIPTION "A program that says hello to people"
)

add_subdirectory(greeter)
add_subdirectory(app)

message("Library scope message: ${LIBRARY_MESSAGE}") #<h>
```


</CodeFile>


When we configure now, we'll see that `LIBRARY_MESSAGE` is empty when accessed from the parent scope. It only existed within the `greeter` subdirectory's scope and was discarded when CMake finished processing that file:


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


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


There are ways in components can communicate with each other outside of these scoping rules, and we'll see some examples of that later in the course.


However, we should be cautious when implementing such designs.  To keep complexity under control, a component's ability to modify the state of its parent or siblings should be extremely limited.


## String Interpolation with Variables


As we've seen, any time you use `${VAR}` inside a double-quoted string, it gets replaced by the variable's value. This is called **string interpolation**.


A common use case for this is to construct file system paths:


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


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

set(SRC_DIR "src")#<h>
set(MAIN_FILE "main.cpp")#<h>

add_executable(GreeterApp src/main.cpp)#<d>
add_executable(GreeterApp "${SRC_DIR}/${MAIN_FILE}")#<h>

target_compile_features(GreeterApp PUBLIC cxx_std_20)
target_link_libraries(GreeterApp GreeterLib)
```


</CodeFile>


### Quoted vs. Unquoted Arguments


How you use quotes when setting a variable is important.  The following are not equivalent:


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


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

# ...

# Quoted argument: The variable is a single string
set(MY_VAR "a b c")
message("Quoted: ${MY_VAR}")

# Unquoted arguments: The variable becomes a list
set(MY_VAR a b c)
message("Unquoted: ${MY_VAR}")
```


</CodeFile>


If we run this, the output shows a subtle but important difference:


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


```c++
//<o>
Quoted: a b c
Unquoted: a;b;c
-- Configuring done (0.1s)
-- Generating done (0.0s)
-- Build files have been written to: D:/Projects/cmake/build
```


When you pass multiple unquoted arguments to `set()`, CMake combines them into a single string, separated by semicolons. This is CMake's syntax for a **list**, which we'll introduce soon.


To deal with this, we should follow a simple convention: if you intend for a variable to be a single string, always enclose its value in double quotes.


## Logging and Printing Messages


The `message()` command is the primary tool that our build script can use to report what is happening. It's how you print variable values, show status updates, and report errors.


We've already used it in its simplest form but, more commonly, we'd pass a "mode" as the first argument to our `message()` command.  Using the `STATUS` mode would look like this:


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


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

set(GREETER_VERSION "1.0")

project(
  Greeter
  VERSION ${GREETER_VERSION}
  HOMEPAGE_URL "https://www.studyplan.dev"
  DESCRIPTION "A program that says hello to people"
)

message(STATUS "Configuring Greeter Version: ${GREETER_VERSION}") #<h>

add_subdirectory(greeter)
add_subdirectory(app)
```


</CodeFile>


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


```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
```


### Common Message Modes

- `NOTICE`: Just prints the text.  This is the default behavior if no mode is provided.
- `STATUS`: Prints the message prefixed with `--`. This is the standard way to display non-critical information to the user during configuration.
- `WARNING`: Prints a warning message prefixed with `CMake Warning:`, but does not stop processing.
- `FATAL_ERROR`: Prints an error message prefixed with `CMake Error:` and _**immediately stops all processing**_.

The following `CMakeLists.txt` demonstrates some of these.  It also includes our first example of conditional logic, which we'll cover in more detail later in this chapter:


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


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

set(GREETER_VERSION "1.0")#<d>

project(
  Greeter
  VERSION ${GREETER_VERSION}
  HOMEPAGE_URL "https://www.studyplan.dev"
  DESCRIPTION "A program that says hello to people"
)

if(DEFINED GREETER_VERSION)#<h>
  message(STATUS "Configuring Version: ${GREETER_VERSION}")#<h>
else()#<h>
  message(FATAL_ERROR "Project version must be specified")#<h>
endif()#<h>

add_subdirectory(greeter)
add_subdirectory(app)
```


</CodeFile>


If we attempt to configure our project without setting `GREETER_VERSION`, we'll see the `FATAL_ERROR` message is now blocking us:


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


```c++
//<o>
CMake Error at CMakeLists.txt:10 (message):
  Project version must be specified

-- Configuring incomplete, errors occurred!
```


## Verbosity and Log Levels


In most systems where logging is important, developers have the option of controlling the **verbosity** of the output.  This lets them control how much information they want to see being reported.


By default, the system will output all messages that use one of the modes we listed above, but we have the option of using less important modes.  These more verbose modes are, in in decreasing level of importance, `VERBOSE`, `DEBUG`, and `TRACE`:


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


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

message(STATUS "This is a status message")
message(VERBOSE "This is verbose message")
message(DEBUG "This is debug message")
message(TRACE "This is trace message")

set(GREETER_VERSION "1.0")

# ...
```


</CodeFile>


Messages that use these less important modes are hidden by default:


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


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


Why is that useful?  The main reason is that, most of the time, people don't want to be flooded with minor messages - they just want the most important information.  However, the _**option**_ to see those less important messages can sometimes be very useful.


The main use case is when the system isn't behaving correctly.  Asking the system to provide more detailed information in such scenarios can help us understand what is going wrong and how to fix it.


### The `--log-level` Option


We ask for this additional information by changing the default verbosity, or "log level", such that messages that were previously hidden will now be displayed.


To specify the verbosity we want to see when configuring our project, we use the `--log-level` setting in the command line.  By setting it to `VERBOSE`, we see messages with `VERBOSE` mode and higher.  Less important messages (`DEBUG` and `TRACE`) are still hidden:


```c++
//<ti>
cmake .. --log-level=VERBOSE
```


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


The `--log-level` options are, in increasing level of detail, `ERROR`, `WARNING`, `NOTICE`, `STATUS` , `VERBOSE`, `DEBUG`, and `TRACE`.


Each option includes messages in the previous categories so, for example, if we set it to `WARNING`, we will see both `WARNING` and `ERROR` messages.  If we set it to `TRACE`, we will see everything.


If no option is set, `STATUS` is the default.


## CMake-Provided Variables


In addition to defining our own variables, there are also a lot of variables that CMake automatically defines for us.  We've already used two of those - `PROJECT_SOURCE_DIR` and `CMAKE_CURRENT_SOURCE_DIR` - which were helpful when defining our include directories.


There are many more system-provided variables.  For example, a side effect of our `project()` command is that it automatically defines a `PROJECT_NAME` variable.


If we provide additional metadata to the command, such as a version number, then variables such as `PROJECT_VERSION`, `PROJECT_VERSION_MAJOR`, `PROJECT_VERSION_MINOR`, and `PROJECT_VERSION_PATCH` will also be available.


We don't want to have two variables for the same information, as failing to keep them in sync can result in bugs.  Therefore, we should remove our custom `GREETER_VERSION` variable, and rely on the system-provided `PROJECT_VERSION` as our single source of truth:


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


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

set(GREETER_VERSION "1.0")#<d>

project(
  Greeter
  VERSION ${GREETER_VERSION}#<d>
  VERSION "1.0" #<h>
  HOMEPAGE_URL "https://www.studyplan.dev"
  DESCRIPTION "A program that says hello to people"
)

if(DEFINED GREETER_VERSION)#<d>
if(DEFINED PROJECT_VERSION)#<h>
  message(STATUS "Configuring Version: ${GREETER_VERSION}")#<d>
  message(STATUS "Configuring Version: ${PROJECT_VERSION}")#<h>
else()
  message(FATAL_ERROR "Project version must be specified")
endif()

add_subdirectory(greeter)
add_subdirectory(app)
```


</CodeFile>


When there is some generic information you need for your `CMakeLists.txt` file, it is likely that CMake has a variable for that.  We'll cover the most common and useful ones as we go through the course, but a full list is available on the [official site](https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html).


## Summary


In this lesson, we took our first steps into the CMake scripting language. These concepts are the bedrock upon which all complex build scripts are built.

- **The** **`set(VAR "value")`** **Command**: Create and update variables. Remember to quote your strings.
- **Using** **`${VAR}`** **to Dereference Variables**: The syntax to use a variable's value.
- **Scope Matters**: Variables flow down into subdirectories but not back up. This keeps components isolated.
- **The** **`message(<mode> "...")`** **Command**: The main tool for debugging and communication. Use `STATUS` for progress reports and `FATAL_ERROR` for validation to create user-friendly error messages.

You now have the fundamental vocabulary to read and write basic CMake scripts.


<Preview>


### The CMake Cache


We've seen that variables are reset every time you run the configure step. But what if you want to set an option - like `BUILD_TESTS=ON` - and have CMake _remember_ it for the next build?


That's the job of the CMake Cache. In the next lesson, we'll explore this special set of variables that persist between builds and how they enable us to create configurable projects.


</Preview>


</Pw>

`set()` Command Documentation

`message()` Command Documentation

CMake Language Syntax

CMake Variables

How to print variables in CMake?

Dive into the core of the CMake language. This lesson covers the essentials of CMake syntax, including how to set and reference variables, understand scope, use string interpolation, and print debug messages with the message() command.

CMake Variables and Logging

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

Managing C++ Projects Using CMake