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

We've explored the build pipeline, wrestled with the command line, and installed the necessary tools. Now, we're going to leave the world of manual compilation behind and write our first `CMakeLists.txt` file.


We'll start with the simplest possible project - a single "Hello, World" executable. Then, we'll progressively build on it, adding a library, linking them together, and specifying the C++ standards.


By the end of this lesson, you'll have a solid, working CMake project and an understanding of the fundamental commands that make it all possible.


## Project Setup and Source Tree


First, let's create a sensible directory structure for our project, following the conventions we discussed in the previous chapter. We'll call our project `Greeter`.


Let's create a root folder named `Greeter`. Inside it, we'll create a `src` directory.


```plain text
//<nh>
Greeter/
└─ src/
```


We'll start with a single source file for a "Hello, World!" program.


<CodeFile path="Greeter/src/main.cpp" status="New">


```c++
#include <iostream>

int main() {
  std::cout << "Hello, CMake!";
  return 0;
}
```


</CodeFile>


That's our project for now. A single source file in a `src` directory. Next, we need to tell CMake how to build it. We do that by creating the special `CMakeLists.txt` file in the root of our project.


## The Minimum CMakeLists.txt


Every CMake project is defined by a text file named `CMakeLists.txt`. This file must be in the root directory of your project.


Let's create this file and add the two fundamental commands that every `CMakeLists.txt` file should have.


<CodeFile path="Greeter/CMakeLists.txt" status="New">


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


</CodeFile>


That's it. This is the bare minimum required for a valid CMake project. Let's break down what these two lines do.


## Setting the CMake Version


The the _**very first line**_ in your top-level `CMakeLists.txt` should be the `cmake_minimum_required()` command. It does two things:

- it checks the version of CMake that is installed on the system, to ensure it meets the requirements of our `CMakeLists.txt` file
- it sets CMake's "policies" to emulate the behavior of that version

Let's describe both of these aspects in a little more detail


### Version Check


Firstly, `cmake_minimum_required()` tells CMake what minimum version is needed to build your project.  Like most software, CMake gets updated over time, and some of those updates include new commands.


If a developer tries to build your project with an older version of CMake that didn't include some of the commands you're using in your `CMakeLists.txt`, this version check will help CMake understand why it doesn't recognize those commands, and explain to the user what the problem is.


### Policy Setting


More importantly, `cmake_minimum_required()` also sets CMake's "policies" to match the behavior of the version you specify. In addition to new commands, CMake updates sometimes change the behavior of existing commands. The `cmake_minimum_required()` line ensures that your project will build predictably, even with newer versions of CMake, because that newer version can emulate the behavior of previous versions.


### What Version Should I Use?


Setting the minimum required version to the latest release is not recommended, unless your project genuinely uses those bleeding edge features and behaviours.


Requiring an extremely recent version when it's not needed forces people to update their development environments to use your project, which can be quite difficult to do in some contexts.  Perhaps they're using a version of CMake that is integrated with their IDE or other tools, and they don't even have the option to update it.


We're setting our `cmake_minimum_required()` to be `3.16` in these examples.  This is chosen somewhat arbitrarily, but the main goal is to select a version that is:

- Old enough to be compatible with the tools that most developers will have installed
- New enough to have access to modern features and likely to be supported in future CMake releases for quite some time.  At the time of writing, the latest version of CMake is `4.1.0` released in August 2025, which can emulate behaviors as far back as version `3.0.5`, released in 2016.

If there is a feature in a newer version of CMake that is useful for solving a problem we have, we'd consider bumping our `cmake_minimum_required()` up to that version.  We'll introduce some of those features later in the course but, for now, something like `3.16` is a reasonable baseline.


<Pw>


## The `project()` Command


This command officially starts the project. It sets the project's name and enables support for programming languages.


`project(Greeter)` sets the name of our project to "Greeter". This name is also stored in the `PROJECT_NAME` variable, which we'll see how to use later. By default, this command also enables support for C and C++.


With just these two commands, we have a valid, albeit empty, CMake project. It doesn't build anything yet, but we've laid the foundation.


## Adding an Executable Target


Now let's tell CMake to actually build something. In CMake, anything that gets built - such as an executable or library - is called a **target**.


The command to create an executable is `add_executable()`. Let's add it to our file.


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


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

add_executable(GreeterApp src/main.cpp) #<h>
```


</CodeFile>


The `add_executable()` command takes two main arguments:


1.  **The Target Name**: The first argument is the name we want to give our executable target.  In simple projects, the primary executable of our project often matches the project name, but it doesn't have to.  Here, we've called our project `Greeter` and the executable `GreeterApp`.
2.  **The Source Files**: The remaining arguments are the source files needed to build that executable. We've provided a single source file for now - `src/main.cpp`.


And that's it! With these three lines, you have a complete, working CMake project that can build an executable. 


We have described **what** we want - an executable named `GreeterApp` built from `main.cpp` - and CMake will figure out **how** to do it on any platform.


We'll run the build in the next lesson, but first, let's make our project a little more complex.


<Aside>


### Adding More Source Files


If our program had more source files, we would simply add them as additional arguments:


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


Like C++, CMake is generally insensitive to white space.  We can add spaces and line breaks as needed to help with readability:


```c++
#<cmake>
add_executable(GreeterApp
  src/main.cpp
  src/second.cpp
  src/third.cpp
  src/fourth.cpp
)
```


We'll cover techniques for managing lists of source files (and lists in general) later in the course.


</Aside>


## Using a Library


Real-world projects are rarely a single file. As we've discussed, good design involves breaking code into logical, reusable components. In C++, we do this with libraries.


This project is obviously too simple to warrant such separation, but let's run with the contrivance to learn the process.  We'll refactor our project into a simple library called `Greeter` that includes a header and source file, and provides a `get_greeting()` function.  Our main executable will then use this library.


### Updating the Project Structure


First, let's create the files for our library. We'll follow the convention of putting the public header in an `include` directory and the source file in `src`.


```c++
//<nh>
Greeter/
├─ include/
│ └─ Greeter.h
└─ src/
  ├─ Greeter.cpp
  └─ main.cpp
```


Here's the content for our new library files, and we'll also update `main.cpp` to use it:


<CodeViewer>


<CodeFile path="Greeter/include/Greeter.h" status="New">


```c++
#pragma once
#include <string>

// A simple function that returns a greeting
std::string get_greeting();
```


</CodeFile>


<CodeFile path="Greeter/src/Greeter.cpp" status="New">


```c++
#include "Greeter.h"

std::string get_greeting() {
  return "Hello from the Greeter library!";
}
```


</CodeFile>


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


```c++
#include <iostream>
#include "Greeter.h" // Include our library's header //<h>

int main() {
  std::cout << get_greeting(); //<h>
  return 0;
}
```


</CodeFile>


</CodeViewer>


Now, we need to update our `CMakeLists.txt` to tell CMake about this new library and how it relates to our executable.


## Adding a Library Target and Linking


We'll use two new commands: `add_library()` to define our library target, and `target_link_libraries()` to create the dependency.  We can also add comments to our `CMakeLists.txt` file using the `#` token:


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


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

# Create a library target named "GreeterLib"
add_library(GreeterLib src/Greeter.cpp) #<h>

# Add our executable target like before
add_executable(GreeterApp src/main.cpp)

# Link the "GreeterLib" library to our executable
target_link_libraries(GreeterApp GreeterLib) #<h>
```


</CodeFile>


Let's break down the new additions.


### `add_library()`


The `add_library(GreeterLib src/Greeter.cpp)` command works just like `add_executable()`. It creates a new library target, where we provide the name we want to use (`GreeterLib` in this example) and the source files it is built from (a single file - `src/Greeter.cpp` - in this example).


By default, this creates a static library (`.a` or `.lib`). We'll learn how to change this to a shared library later in the course.


In real-world projects, libraries are generally going to have more sensible names based on their specific purpose.  They might have names such as "Renderer" or "PhysicsEngine".


In our contrived example, we'll call our target `GreeterLib`, to distinguish it from the overall project (which we called `Greeter`) and the executable target (which we called `GreeterApp`).


### `target_link_libraries()`


The `target_link_libraries(GreeterApp GreeterLib)` command connects the library to the executable. It tells CMake, that the `GreeterApp` target depends on the `GreeterLib` target.  This single command does several things for us automatically:

- It ensures `GreeterLib` is built before `GreeterApp`.
- It tells the linker to link the compiled `GreeterLib` library with the `GreeterApp` executable.
- As we'll see later, it can also transitively pass on configuration options and usage requirements, like include directories.

## Adding Include Directories


We still have one problem. The `main.cpp` file includes `Greeter.h`, but the compiler doesn't know to look in our `include` directory for this header file. Let's fix that:


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


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

add_library(GreeterLib src/Greeter.cpp)

# Tell our GreeterLib library where its public headers are
target_include_directories(GreeterLib PUBLIC #<h>
  ${PROJECT_SOURCE_DIR}/include #<h>
) #<h>

add_executable(GreeterApp src/main.cpp)

target_link_libraries(GreeterApp GreeterLib)
```


</CodeFile>


The `target_include_directories()` command adds include search paths to a target.  Let's break down the three arguments we provided here.


### The `GreeterLib` Argument


The include directory we want to provide relates to our `GreeterLib` library, so we provide this target as the first argument.


Our `GreeterApp` target also needs this include directory for the `#include` directive in it's `main.cpp` file, so you might think we need a second `target_include_directories()` for that target.


We could add that, but one of the benefits of CMake is that we don't need to.  As long as our library makes this include directory `PUBLIC` and we then link to the library using `target_link_libraries()`, CMake can take care of it for us.  This management of interconnected targets is a major feature of CMake and something we've dedicated a chapter to later in the course.


### The `PUBLIC` Argument


The `PUBLIC` keyword effectively makes this dependency known to any other target that might be interested. It means: "Anyone who links to me (`GreeterLib`) also needs this include directory to compile."


In our case, the `GreeterApp` also needs to know about this include directory.  Because we made this relationship `PUBLIC`, and we later we link `GreeterApp` to `GreeterLib`, then `GreeterApp` automatically inherits the include directory, solving our compilation problem.


We'll fully explain the `PUBLIC` keyword and the other options - `PRIVATE` and `INTERFACE` - later in the course.


### The Include Directory


Finally, as our third argument, we need to provide the actual path to our `/include` directory.


We do this using the `${PROJECT_SOURCE_DIR}/include` expression, which is our first example of using a **variable** within CMake.  We'll cover variables in much more detail soon, but `PROJECT_SOURCE_DIR` a one of the many variables that CMake automatically defines for us.


It's value is the path on our file system to our project directory - that is, the location where our `CMakeLists.txt` file is.  The `${PROJECT_SOURCE_DIR}/include` interpolates this variable into a string to generate the full path to our `/include` folder within our project's directory.


If the header files for our `GreeterLib` library were instead located in `/greeter/include` within our project directory, then our expression would look like this:


```c++
#<cmake>
target_include_directories(GreeterLib PUBLIC
  ${PROJECT_SOURCE_DIR}/greeter/include #<h>
)
```


If our library had multiple include directories, we can add additional arguments to our `target_include_directories()` command:


```c++
#<cmake>
target_include_directories(GreeterLib PUBLIC
  ${PROJECT_SOURCE_DIR}/include
  ${PROJECT_SOURCE_DIR}/headers#<h>
  ${PROJECT_SOURCE_DIR}/more-headers#<h>
)
```


## Specifying C++ Standards


The final piece of our basic puzzle is telling CMake which version of the C++ standard we want to use.


Modern CMake provides a target-based way to do this with `target_compile_features()`.  We should do this for both of our library and executable targets.  We'll use C++20 in this example, but not for any specific reason beyond it being a relatively modern and widely supported baseline:


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


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

add_library(GreeterLib src/Greeter.cpp)
target_compile_features(GreeterLib PUBLIC cxx_std_20) #<h>
target_include_directories(GreeterLib PUBLIC
  ${PROJECT_SOURCE_DIR}/include
)

add_executable(GreeterApp src/main.cpp)
target_compile_features(GreeterApp PUBLIC cxx_std_20) #<h>
target_link_libraries(GreeterApp GreeterLib)
```


</CodeFile>


The command `target_compile_features(MyTarget PUBLIC cxx_std_20)` tells CMake: "The target `MyTarget` requires compiler features associated with the C++20 standard."


CMake will then automatically add the correct compiler flag (e.g., `-std=c++20` for GCC/Clang or `/std:c++20` for MSVC) when compiling that target.


Just like with `target_include_directories()`, the `PUBLIC` keyword makes this requirement propagate between targets.  We'll fully explain this propagation process, the `PUBLIC` keyword, `target_compile_features()` and managing compiler flags later in the course.


<Aside>


### Targeted vs Global Configuration


Sometimes, the C++ standard is set via the `CMAKE_CXX_STANDARD` variable using a command like `set(CMAKE_CXX_STANDARD 20)`. While this works, the target-based approach is preferred for several reasons:

- **Granularity**: It allows you to have different targets in the same project use different C++ standards if necessary.  For example, an older library you're integrating might require C++17, while your new code uses C++20.
- **Clarity**: It makes dependencies explicit. Looking at a target's definition, you can see exactly what standard it requires.
- **Transitivity**: The `PUBLIC` and `INTERFACE` keywords allow you to propagate requirements to dependent targets automatically.  This is a core principle of modern CMake that we'll cover in more detail later.

This advice applies to many other cases, too.  For example, global equivalents of most of the commands we introduced in this section are available, but we should prefer the newer `target_` variations:

- Prefer `target_compile_features()` over `set(CMAKE_CXX_STANDARD ...)`
- Prefer `target_include_directories()` over `include_directories()`
- Prefer `target_link_libraries()` over `link_libraries()`

</Aside>


## Summary


We now have a complete, modern `CMakeLists.txt` file documenting the full configuration of a simple project with both a library and an executable.


Let's review our final `CMakeLists.txt` for this lesson:


<CodeViewer>


<CodeFile path="Greeter/include/Greeter.h">


```c++
#pragma once
#include <string>

std::string get_greeting();
```


</CodeFile>


<CodeFile path="Greeter/src/Greeter.cpp">


```c++
#include "Greeter.h"

std::string get_greeting() {
  return "Hello from the Greeter library!";
}
```


</CodeFile>


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


```c++
#include <iostream>
#include "Greeter.h"

int main() {
  std::cout << get_greeting();
  return 0;
}
```


</CodeFile>


<CodeFile path="Greeter/CMakeLists.txt" defaultOpen>


```c++
#<cmake>
# 1. Set the minimum CMake version and project name
cmake_minimum_required(VERSION 3.16)
project(Greeter)

# 2. Define the library target
add_library(GreeterLib src/Greeter.cpp)

# 3. Add usage requirements to the library
target_compile_features(GreeterLib PUBLIC cxx_std_20)
target_include_directories(GreeterLib PUBLIC
  ${PROJECT_SOURCE_DIR}/include
)

# 4. Define the executable target
add_executable(GreeterApp src/main.cpp)

# 5. Add usage requirements to the executable
target_compile_features(GreeterApp PUBLIC cxx_std_20)

# 6. Link the library to the executable
target_link_libraries(GreeterApp GreeterLib)
```


</CodeFile>


</CodeViewer>


We've learned the five most fundamental commands for any CMake project:

- `cmake_minimum_required()`: Sets the required version and policies.
- `project()`: Names the project.
- `add_library()`: Creates a library target.
- `add_executable()`: Creates an executable target.
- `target_link_libraries()`: Creates a dependency between targets.

And we've seen how to add requirements like include paths and C++ standards using modern, target-based commands.


<Preview>


### Let's Build It!


Our `CMakeLists.txt` is set up, but it's just a text file. It hasn't actually built anything yet.


In the next lesson, we will walk through the two-stage process of a CMake build: **configuring** the project to generate a native build system, and then **building** the project to compile and link our targets.


We'll do this from the command line and see how to troubleshoot the initial, common errors that can pop up.


</Preview>


</Pw>

Fixed explanation referring to the target as `Greeter` instead of `GreeterLib`.  Added notes on `add_executable()`, `add_library()`, and `target_include_directories()` supporting multiple paths

Setting Up the CMake Environment

Building and Running the CMake Project

CMake Tutorial

`cmake_minimum_required()` Docs

`project()` Docs

`add_executable()` Docs

`add_library()` Docs

`target_link_libraries()` Docs

`target_compile_features()` Docs

Professional CMake: A Practical Guide

Learn to write your first CMakeLists.txt file with this step-by-step tutorial. We cover project setup, cmake_minimum_required, project(), add_executable(), add_library(), and target_link_libraries() to build a C++ project with an executable and a library.

Writing a CMakeLists File

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

Managing C++ Projects Using CMake