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

As our `CMakeLists.txt` scripts grow, they risk becoming cluttered and repetitive, just like C++ code without functions. We've seen how `target_compile_features()` and `target_include_directories()` need to be applied to multiple targets. Copying and pasting this logic is not a scalable solution.


The answer, just as in any good programming language, is to modularize our code. CMake provides several mechanisms for this, allowing us to package reusable logic into self-contained units.


This lesson will introduce the three main tools for achieving modularity in CMake:

- **Functions**: To encapsulate logic into reusable commands with their own private scope.
- **Macros**: A simpler alternative to functions that operates in the caller's scope.
- **Modules**: Separate `.cmake` files that can be loaded into our project to provide functions and macros that can be shared across multiple scripts.

## Creating Reusable Logic with Functions


A CMake `function` is the primary way to bundle a sequence of commands into a single, new command that you can call repeatedly. It's the direct equivalent of a function in C++ or other programming languages.


The basic syntax is:


```c++
//<cmake>
function(<FunctionName> [arg1 arg2 ...])
  # Commands to be executed
  # Arguments are available as ${arg1}, ${arg2}, etc.
endfunction()
```


Let's create a practical example. In our current project, we have to set the C++ standard for every library and executable we create. This is a perfect candidate for a helper function.


Let's create a `setup_target()` function in our root `CMakeLists.txt` that takes a target name as an argument and applies our standard C++20 configuration to it.


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


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

project(Greeter VERSION "1.0")

# Define a reusable function
function(setup_target target_name) #<h>
  message(STATUS#<h>
    "Setting C++20 standard for: ${target_name}"#<h>
  ) #<h>
  target_compile_features(${target_name} PUBLIC cxx_std_20) #<h>
endfunction() #<h>

add_subdirectory(greeter)
add_subdirectory(app)
```


</CodeFile>


This `setup_target()` function is now available at any point in this `CMakeLists.txt` file below where it is defined.  Bearing in mind how scoping rules work, it will also be available in any "child" `CMakeLists.txt` file loaded through the `add_subdirectory()` command.


Let's use this to replace the `target_compile_features()` calls in our other `CMakeLists.txt` files with calls to our new function.


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


```c++
#<cmake>
cmake_minimum_required(VERSION 3.16)
add_library(GreeterLib src/Greeter.cpp)

setup_target(GreeterLib) #<h>

target_include_directories(GreeterLib PUBLIC
  "${CMAKE_CURRENT_SOURCE_DIR}/include"
)
```


</CodeFile>


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


```c++
#<cmake>
cmake_minimum_required(VERSION 3.16)
add_executable(GreeterApp src/main.cpp)

setup_target(GreeterApp) #<h>

target_link_libraries(GreeterApp GreeterLib)
```


</CodeFile>


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


```c++
//<o>
-- Setting C++20 standard for target: GreeterApp
-- Setting C++20 standard for target: GreeterLib
-- Configuring done (0.8s)
-- Generating done (0.1s)
-- Build files have been written to: D:/Projects/cmake/build
```


This is already much cleaner. If we decide to move to C++23, we only need to change it in one place: inside our `setup_target()` function.


<Aside>


### Parsing Function Arguments


Beyond simple named arguments, CMake provides several special variables inside a function to handle arguments:

- `ARGC`: The total count of arguments passed.
- `ARGN`: A list of all arguments _after_ the last named argument.  This allows us to replicate the behavior of  variadic functions within CMake - that is, functions that can handle an unknown number of arguments.
- `ARGV`: A list of all arguments passed - both named and unnamed.

```c++
cmake_minimum_required(VERSION 3.16)

function(handle_list arg1 arg2)
  message("I was called with ${ARGC} arguments")
  message("The named parameters are ${arg1} and ${arg2}")
  message("The additional unnamed parameters are ${ARGN}")
  message("All parameters: ${ARGV}")
endfunction()

handle_list(Apple Banana Cherry Potato)
```


```c++
//<o>
I was called with 4 arguments
The named parameters are Apple and Banana
The additional unnamed parameters are Cherry;Potato
All parameters: Apple;Banana;Cherry;Potato
```


For creating functions that take optional keyword arguments, such as the `STATUS` keyword in a function like `message(STATUS "Hello")`, the modern approach is to use the `cmake_parse_arguments()` command.  We will explore this command in a later lesson.


</Aside>


<Pw>


## Macro vs. Function: The Scope Difference


At first glance, a CMake `macro` looks identical to a `function`. The definition syntax is nearly the same:


```c++
macro(<MacroName> [arg1 arg2 ...])
  # Commands to be executed
endmacro()
```


However, there is one fundamental difference: **scope**.

- A **function** creates a new scope. Variables defined inside a function are local to that function and are destroyed when the function returns. They do not affect the caller's scope.
- A **macro** does not create a new scope. When you call a macro, its code is effectively expanded and executed directly in the caller's scope. Any variables set or modified inside a macro will alter the state of the calling `CMakeLists.txt`.

### A Demonstration of Scope


Let's see this with a simple experiment:


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

function(scope_test_func)
  set(TEST_VAR "Set inside function")
  message("Inside function: TEST_VAR is ${TEST_VAR}")
endfunction()

macro(scope_test_macro)
  set(TEST_VAR "Set inside macro")
  message("Inside macro: TEST_VAR is ${TEST_VAR}")
endmacro()

# Call the function and check the variable
scope_test_func()
message("After function call: TEST_VAR is '${TEST_VAR}'")

# Call the macro and check the variable
scope_test_macro()
message("After macro call: TEST_VAR is '${TEST_VAR}'")
```


When we configure this project, the output shows the difference:


```c++
//<o>
Inside function: TEST_VAR is Set inside function
After function call: TEST_VAR is ''
Inside macro: TEST_VAR is Set inside macro
After macro call: TEST_VAR is 'Set inside macro'
```


The variable set by the function vanished as soon as the function finished. The variable set by the macro persisted and overwrote any existing variable in the parent scope.


### When to Use Which?


The scoping behavior dictates the use case:

- **Use functions by default.** Their isolated scope makes them safer and more predictable. They prevent accidental modification of variables in the parent scope, which is a common source of hard-to-find bugs. Functions are for encapsulating a logical sequence of operations.
- **Use macros only when you explicitly need to modify the parent scope.** They are useful for creating short, utility "commands" that need to return a value by setting a variable for the caller.

Modern CMake best practice strongly favors functions over macros.


## Returning Values from Functions


CMake functions do not support "returning" values in the traditional sense, but we can accomplish something similar by using a `set()` command with the `PARENT_SCOPE` option.


Below, we define a function that accepts the name of an output variable, and then sets a variable with that name in the scope where the function was called:


```c++
#<cmake>
function(get_full_name output_var first last)
  set(${output_var} "${first} ${last}" PARENT_SCOPE)
endfunction()

get_full_name(my_name "John" "Doe")
# my_name is now "John Doe"
```


The `PARENT_SCOPE` option only allows us to set or update variables in the immediate parent scope - it doesn't let us directly update values in grandparent scopes, or any further up the hierarchy.


So, for example, if we were to call `get_full_name()` from a `CMakeLists.txt` file loaded by `add_subdirectory()`, the invocation would set the variable within the scope of that `CMakeLists.txt` file, not the file where the function was defined.


In the next chapter, we'll introduce **properties**, which give us some alternative options over where we store our variable data.


## Including External CMake Modules


As our collection of helper functions and macros grows, we don't want to clutter our top-level `CMakeLists.txt` with them. The solution is to move them into separate files called **modules** and bring them into our project when needed.


### The `include()` Command


The `include()` command tells CMake to find a `.cmake` file and execute it in the current scope, much like `#include` in C++. Once the module is included, all functions and macros defined within it become available for use.


Let's refactor our project by moving our `setup_target()` function into its own module.


**Step 1: Create the Module File**


It's a common convention to place project-specific modules in a `cmake/` directory at the project root.


<CodeFile path="cmake/TargetHelpers.cmake" status="New">


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

# This file contains helper functions for setting up targets.
function(setup_target target_name)
  message(STATUS
    "Setting C++20 standard for: ${target_name}"
  )
  target_compile_features(${target_name} PUBLIC cxx_std_20)
endfunction()
```


</CodeFile>


**Step 2: Include the Module**


Now, in our root `CMakeLists.txt`, we can remove the function definition:


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


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

project(Greeter VERSION "1.0")

function(setup_target target_name) #<d>
  message(STATUS#<d>
    "Setting C++20 standard for: ${target_name}"#<d>
  ) #<d>
  target_compile_features(${target_name} PUBLIC cxx_std_20) #<d>
endfunction() #<d>

add_subdirectory(greeter)
add_subdirectory(app)
```


</CodeFile>


Instead, files that need this function can load it in using an `include()` command:


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


```c++
#<cmake>
cmake_minimum_required(VERSION 3.16)
include(../cmake/TargetHelpers.cmake)#<h>

add_library(GreeterLib src/Greeter.cpp)
setup_target(GreeterLib)
target_include_directories(GreeterLib PUBLIC
  "${CMAKE_CURRENT_SOURCE_DIR}/include"
)
```


</CodeFile>


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


```c++
#<cmake>
cmake_minimum_required(VERSION 3.16)
include(../cmake/TargetHelpers.cmake)#<h>

add_executable(GreeterApp src/main.cpp)
setup_target(GreeterApp)
target_link_libraries(GreeterApp GreeterLib)
```


</CodeFile>


The behavior is identical, but our root `CMakeLists.txt` is now cleaner and is back to remaining focused on the high-level project details.


### Setting `CMAKE_MODULE_PATH`


When you call `include()` (or `find_package()`, which we'll cover later), CMake searches for the specified module in a list of predefined locations. You can add your own directories to this search path by modifying the `CMAKE_MODULE_PATH` variable.


It's a common pattern to add your project's `cmake` directory to this path:


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


```c++
#<cmake>
cmake_minimum_required(VERSION 3.16)
list(APPEND CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake")#<h>

project(Greeter VERSION "1.0")

add_subdirectory(greeter)
add_subdirectory(app)
```


</CodeFile>


This means that our modules can now be imported just using their name - we no longer need to provide the path and file extension.  For example:


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


```c++
#<cmake>
cmake_minimum_required(VERSION 3.16)
include(../cmake/TargetHelpers.cmake)#<d>
include(TargetHelpers)#<h>

add_executable(GreeterApp src/main.cpp)
setup_target(GreeterApp)
target_link_libraries(GreeterApp GreeterLib)
```


</CodeFile>


## Standard and Third-Party Modules


We don't need to write everything ourselves.  Much like C++ includes a standard library of useful utilities, CMake comes with a large collection of utility modules that provide helpful functions and macros for common tasks.  You just need to `include()` them to use their features.


A simple example is the `CMakePrintHelpers` module. We've already learned how to print variables using the `message()` command. This works, but if you want to inspect several variables, the code can get repetitive:


```c++
#<cmake>
message("VAR1 = ${VAR1}")
message("VAR2 = ${VAR2}")
message("VAR3 = ${VAR3}")
```


The `CMakePrintHelpers` module offers a more convenient way to do this with its `cmake_print_variables()` function.


Let's see how to use it. First, we `include()` the module. Then, we can call the function it provides, passing the names of all the variables we want to inspect.


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

# Include the standard CMake module
include(CMakePrintHelpers) #<h>

set(MY_STRING "Hello")
set(MY_LIST "a;b;c")
set(MY_BOOL ON)

# Use the function from the module to print the variables
cmake_print_variables(MY_STRING MY_LIST MY_BOOL) #<h>
```


When we configure this project, `cmake_print_variables()` gives us a clean, formatted output showing the name and value of each variable we requested:


```plain text
//<o>
-- MY_STRING="Hello"
-- MY_LIST="a;b;c"
-- MY_BOOL="ON"
```


This is much cleaner and more readable than writing multiple `message()` calls.


Many common problems, from finding specific compilers to interacting with version control systems, already have solutions in the form of a standard module.  You can see the full list of official modules on [the CMake site](https://cmake.org/cmake/help/latest/manual/cmake-modules.7.html).  


Given CMake's popularity, there is also a huge community of people making and sharing resources, including modules for solving a wide range of problems.  The [awesome-cmake repository on GitHub](https://github.com/onqtam/awesome-cmake) curates a list of the best community-built resources.


## Summary


Modularizing your CMake code is helpful for creating clean, scalable, and maintainable build systems. Just as you refactor C++ code to avoid repetition, you should refactor your complex `CMakeLists.txt` files.

- **Functions for Reusable Logic**: Use `function()` to encapsulate sequences of commands. They are the preferred tool because their private scope prevents unintended side effects.
- **Macros for Scope Modification**: Use `macro()` sparingly, and only when you have a clear need to set or modify a variable in the calling scope.
- **Modules for Sharing Code**: Move your helper functions and macros into separate `.cmake` files.
- **Loading Modules**: Use the `include()` command to bring your helper modules into a `CMakeLists.txt`, making their functions available for use.

<Preview>


### Targets and Dependencies


We've learned how to create functions that apply settings to targets. Now it's time to learn more about what a "target" really is. In modern CMake, a target is more than just a name; it's an object with a rich set of properties that define how it's built and, more importantly, how it's **used**.


In the next chapter, we will explore the core concepts of targets and properties, including the `PUBLIC`, `PRIVATE`, and `INTERFACE` keywords that control how usage requirements are propagated between dependencies.
</Preview>


</Pw>

Minor improvements to explanations and writing style

Targets and Properties in Modern CMake

`function()` Command Documentation

`macro()` Command Documentation

`include()` Command Documentation

`cmake_parse_arguments()` Command Documentation

What is the difference between a macro and a function in CMake?

It's Time To Do CMake Right

Master CMake modularity by learning to write functions and macros. This guide covers the difference between them, variable scope, and how to use include() to load external .cmake modules, transforming your scripts into clean, reusable code.

Modularizing CMake Code

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

Managing C++ Projects Using CMake