An introduction to the build pipeline, and how we can orchestrate it manually

Before working with CMake, it's useful to understand the tools it orchestrates. This lesson guides you through setting up a C++ toolchain.

Building C++ Programs

Walking through the steps of the C++ compilation process, from source code to machine code.

The Compilation Pipeline

The linker's role in the build process, how it resolves symbols to combine object files, and how to troubleshoot common errors.

Object Files and the Linking Process

The difference between static and dynamic libraries, how to create them, and the trade-offs between them.

Static and Shared Libraries

The C++ Build Process

Recommended approaches for managing large projects and the libraries that they depend on

Learn how to structure your C++ projects for scalability and maintainability, from basic directory layouts to managing multiple modules.

Organizing a C++ Project

Learn to manage third-party libraries in C++, covering include/library paths, static vs. shared libraries, versioning, and platform differences.

Managing Libraries and Dependencies

An introduction to traditional build tools like Makefiles and IDE projects, highlighting the maintenance, scalability, and cross-platform challenges that result

Automated Build Systems and Their Limitations

Project Structure and Dependency Management

Setting up CMake and creating your first project

An introduction to CMake, the cross-platform, open-source meta-build system that solves the core challenges of C++ project management.

Why CMake?

A step-by-step guide to installing CMake. We'll explore command-line, GUI, and IDE workflows, and how to configure your compiler.

Setting Up a CMake Environment

Creating the bare minimum `CMakeLists.txt` file and build up to a project with an executable and a library, learning the fundamental commands along the way.

Writing a CMakeLists File

Learn the two-stage process of building a CMake project. This lesson covers configuring, generating, building, running, and troubleshooting common errors.

Building and Running CMake Projects

Learn how to organize large C++ projects in CMake using subdirectories and the `add_subdirectory()` command to create modular, maintainable builds.

CMake Project Structure and Subdirectories

Introducing CMake

Exploring CMake's programming features, caching mechanisms, and interactions with the file system

A primer on the fundamental building blocks of the CMake language: variables, string interpolation, and logging messages.

CMake Variables and Logging

Discover the CMake Cache, the mechanism for storing persistent user-configurable options, and learn how to create and manage cached variables.

The CMake Cache

Exploring CMake's command syntax and its list data type, including how to create, manipulate, and use lists in your projects.

CMake Commands, Arguments, and Lists

Transform your static build descriptions into dynamic scripts with CMake's control flow commands, if() and foreach().

CMake Conditionals and Loops

Exploring CMake's `file()` command, covering how to read, write, copy, and glob files, and how to manipulate paths.

Working with the File System

Learn to create reusable logic with CMake functions and macros, and how to organize them into modules for clean, scalable build systems.

Modularizing CMake Code

CMake Language and Fundamentals

Learn more about targets, and how their properties and links are the foundation of modern CMake

Learn to work with target properties - understanding their purpose, setting and updating them, and retrieving them when your build requires it

Target Properties

Learn about target types, and how the `PUBLIC`, `PRIVATE`, and `INTERFACE` keywords control how properties are shared.

Relationships Between Targets

Discover how CMake's `target_link_libraries()` command builds a dependency graph, and how it uses this graph to automatically manage transitive dependencies and link order.

Indirect Relationships and the Dependency Graph

Learn to use abstract target types like `INTERFACE`, `ALIAS`, and `IMPORTED` to model complex project needs, organize build properties, and integrate pre-compiled binaries.

Using `INTERFACE`, `ALIAS`, and `IMPORTED` Libraries

Adding support for user-configurable library types and an initial introduction to target installation.

Using Shared Libraries

Targets and Dependencies

Learn how to manage multiple build configurations within the same project, and how to create scripts that adapt to the environment

Learn how CMake manages different build configurations like Debug and Release, the difference between generator types, and how to apply settings conditionally using modern techniques.

Build Configurations (Debug, Release, etc.)

Learn the tools and patterns needed to write portable CMakeLists.txt files that work seamlessly across platforms and compilers

Cross-Platform Configurations

Learn to write architecture-aware CMake scripts for 32/64-bit systems and Apple's Universal Binaries (Intel/ARM).

Handling Different Architectures

Learn to build for different operating systems and architectures using CMake's cross-compilation support and toolchain files.

Cross-Compilation and Toolchain Files

Platforms and Build Configurations

Learn how to add external libraries to our build, and how to create our own packages for others to use

Learn to find and use pre-installed libraries with `find_package()`, understanding Module vs. Config mode and the power of imported targets

Finding Dependencies using `find_package()`

Learn how to make your libraries consumable by other projects using CMake by turning your build-tree into a distributable install-tree.

Creating a Consumable Package

Learn how to consume a CMake package you've installed, completing the producer-consumer cycle. We'll cover using `find_package()` and how to point CMake to your library's location

Using Installed Packages

Learn how to create self-contained, reproducible builds by fetching dependencies from source using `FetchContent()` and `ExternalProject_Add()`.

Fetching External Dependencies

Creating and Consuming Packages

Integrating the vcpkg and Conan package managers to handle external dependencies

Learn to manage C++ dependencies effortlessly with the vcpkg package manager and its seamless CMake integration using toolchain files and manifests.

Integrating CMake and vcpkg

Learn the day-to-day commands for managing dependencies with vcpkg and how to guarantee reproducible builds using baselines and version overrides

vcpkg Commands and Versioning

Combine vcpkg with CMake's cross-compilation capabilities. Learn to use triplets to target different architectures and chain-load toolchain files

Cross-Compiling with vcpkg

Discover Conan, the binary-first C++ package manager, and learn how to integrate it with CMake using profiles and lockfiles for fast, reproducible builds.

Using Conan with CMake

Learn to cross-compile C++ projects with Conan, using build and host profiles to manage dependencies for different platforms.

Cross-Compilation with Conan

Package Managers

Introducing presets, allowing us to simplify our workflow and share common configurations across our team

Learn the fundamentals of CMake Presets. This lesson introduces `CMakePresets.json` to simplify complex build commands.

CMake Presets

Learn to structure your CMake presets with inheritance and customize them for your local environment using `CMakeUserPresets.json`.

User Presets and Inheritance

Learn to make your CMake presets portable by using environment variables and conditional logic to adapt to different machine configurations.

Environment Variables and Conditional Presets

Learn how to extend the build process beyond simple compilation by integrating external tools and custom commands

Learn how to use generator expressions `$<...>` for build-time conditional logic.

Generator Expressions and Conditional Logic

Learn how to attach commands to specific points in a target's build lifecycle using `add_custom_command(TARGET)` for tasks like post-build file copying.

Integrating Tools with `add_custom_command()`

Learn to integrate code generators like Protobuf into your build process using `add_custom_command()`, creating automated file-level dependencies in CMake.

Generating Files with Protobuf and `add_custom_command()`

Custom Commands

An introduction to automating common workflow chores by creating custom targets

Learn to create standalone, non-code targets using add_custom_target() for utility tasks like code formatting and documentation generation.

Custom Targets and Build Utilities

Using the Clang-Format tool to automatically enforce a consistent coding style, and integrating it into our build using a custom CMake target

Using Clang-Format

An introduction to file sets and the `target_sources()` command, allowing us to manage our header files in a more controlled way

Using File Sets

A step-by-step guide to integrating Doxygen into your CMake build process for automated C++ documentation.

Generating Documentation with Doxygen

Custom Targets

Integrate automated tests into a CMake project using CTest, GoogleTest, and GoogleMock

Learn the fundamentals of automated testing in C++ with CTest. Create your first test suite, register tests with `add_test()`, and run them with the `ctest` command.

Automated Testing and CTest

Learn to refactor manual C++ tests into a professional test suite using the GoogleTest framework, managed by vcpkg and integrated with CTest.

Integrating GoogleTest with CMake

Learn to use a wide range of assertions, write data-driven parameterized tests, and isolate dependencies with Google Mock.

Assertions and Parameterized Tests

Learn how to isolate dependencies that our project uses, and then how to replace those dependencies at test time using Google Mock.

Dependency Injection and Mocking

Learn the standard pattern for testing application logic by refactoring it into a linkable library

Testing Executables

Move beyond individual tests to manage a full test suite. Learn to organize tests, run tests in parallel, filter by labels, and measure our code coverage

Managing a Test Suite

Automated Testing

Using static and dynamic analysis in CMake projects to automatically detect memory bugs, performance issues, and problematic code

Learn to find memory bugs at runtime by integrating AddressSanitizer (ASan) into a CMake project

Using AddressSanitizer (ASan)

Adding benchmarks to our build to measure the performance of our code, and track how it changes over time

Using Google Benchmark

Integrating Clang-Tidy to enforce good practices and find bugs before we even compile

Using Clang-Tidy

Automated Analysis

Automating the entire development lifecycle using Git for souce control, GitHub Actions for cloud builds, and CPack to create distributable packages and installers.

An introduction to Git, the version control system that underpins modern collaborative software development and automated build pipelines.

Source Control with Git

Learn how to automate your build and test process with Continuous Integration (CI) and a build server. This lesson provides a guide to creating a GitHub Actions workflow for a CMake project.

Build Servers and Continuous Integration

Learn to package your C++ projects using CMake's CPack. This lesson covers creating developer ZIP archives and professional Windows MSI installers with components.

Packaging with CPack

Learn to automate the packaging process by integrating CPack with a multi-platform GitHub Actions workflow

Packaging with GitHub Actions

Learn to automate the creation of a professional Windows installer by integrating CPack, the WiX Toolset, and a multi-platform GitHub Actions workflow.

Creating Installers with CPack and GitHub Actions

Learn to automate the release process using a GitHub Actions workflow that builds, packages, and publishes artifacts to a GitHub Release

Deployment with GitHub Releases

Continuous Integration and Packaging

If you have a basic grasp of C++ but find the build process intimidating, this course is for you. We assume you know the language, but not how to manage large projects.

Manage complex, cross-platform builds using industry-standard tools. Create scalable build systems that automate the entire development lifecycle.

This course is a comprehensive deep-dive into the entire C++ build ecosystem, centered around the power and flexibility of modern CMake. We leave no stone unturned.

Start with a foundational understanding of compilers, linkers, static vs. shared libraries, and object files.

The Full Build Pipeline

Learn every aspect of the CMake language, from variables and control flow to functions, modules, and generator expressions.

Complete CMake Language Mastery

Master the modern target-centric paradigm, including properties, usage requirements, and abstract targets.

Advanced Target Management

Explore every method for handling dependencies, from `find_package` and `FetchContent` to vcpkg and Conan, including versioning and cross-compilation.

In-Depth Dependency Management

Integrate a full suite of professional tools for testing (CTest, GoogleTest), analysis (ASan, Clang-Tidy), and packaging (CPack).

Total Workflow Automation

Build a fully automated deployment pipeline that takes your code from a Git push to a published GitHub Release with multi-platform installers.

End-to-End CI/CD and Deployment

What You'll Learn

Become a software engineer with C++.  Starting from the basics, we guide you step by step along the way

Intro to C++ Programming

If you're completely new to programming or want a thorough introduction, consider starting with our free introductory course:

New to Programming?

Managing C++ Projects Using CMake

In our last lesson, we crafted our very first `CMakeLists.txt` file. We took a simple C++ project with a library and an executable and described its structure using CMake's high-level commands. That file is our blueprint, the single source of truth for our build.


Right now, our `CMakeLists.txt` is just a text file. It hasn't compiled any code or produced an executable. In this lesson, we'll walk through the two-stage process of using CMake to build our software: **configuring** a native build system and then **building** our targets.


We'll use the basic project we set up in the previous lesson, which is provided below:


<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_include_directories(GreeterLib PUBLIC
  ${PROJECT_SOURCE_DIR}/include
)
target_compile_features(GreeterLib PUBLIC cxx_std_20)

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


## Running CMake to Generate Build Files


The first step in any CMake workflow is the **configure** step. This is where CMake reads your `CMakeLists.txt` file, finds a suitable compiler, and generates the native build files for your platform (like a `Makefile` on Linux or a Visual Studio `.sln` file on Windows).


### Out-of-Source Builds


Before we run our first command, we should introduce a common best practice: the **out-of-source build**.


This means that all the files generated by the build process - Makefiles, object files, executables, everything - should live in a directory that is **separate** from your source code and other project files. The most common convention is to create a `build` directory inside your project's root folder.


Why is this important?

- **Cleanliness**: The other directories in your file system remains pristine and only contains the files you actually maintain.
- **Easy Cleanup**: To completely clean your project of automatically generated files and start fresh, you just delete the `build` directory. There's no risk of accidentally deleting an important file.
- **Multiple Configurations**: You can have multiple build directories for different configurations (e.g., `build-debug`, `build-release`, `build-for-arm`) side-by-side, all using the same source code.

Let's set up this directory using our operating system's UI, or via a terminal.  Using a terminal, we'd first navigate the root of our `Greeter` project using the `cd` command:


```c++
//<ti>
cd path/to/Greeter
```


We can create a `build` directory in that location using `mkdir`:


```c++
//<ti>
mkdir build
```


Now, we navigate _**into**_ the newly created `build` directory. All our build commands will be run from here:


```c++
//<ti>
cd build
```


**Important:** Throughout the rest of the course, we'll always run our terminal commands from this `build` directory, unless stated otherwise.  If you're following along with a lesson and one of the commands doesn't work, the first thing you should check is that the command is being run from the `build` directory.


If you're more experienced with the terminal, feel free to run them from other locations, replacing path arguments such as `..` and `.` arguments in our examples with the correct locations.


### Running the `cmake` Command


From inside the `build` directory, we'll run the configure step, which just involves the `cmake` command and the location of our `CMakeLists.txt` file:


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


The `..` tells CMake that the `CMakeLists.txt` is "one level up" from our current location.  So, if our terminal is in the `/Greeter/build` directory, `..` refers to the `/Greeter` directory.


Assuming our `CMakeLists.txt` is indeed in that directory, we'll see CMake get to work with output that might look something like this:


```c++
//<o>
-- Building for: Ninja
-- The C compiler identification is GNU 15.1.0
-- The CXX compiler identification is GNU 15.1.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: D:/msys64/ucrt64/bin/cc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: D:/msys64/ucrt64/bin/c++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (9.0s)
-- Generating done (0.0s)
-- Build files have been written to: D:/Projects/cmake/build
```


If this command doesn't work, we've included some troubleshooting steps at the end of this lesson.  But, if it has worked, we'll see that CMake has successfully:

1. Found a C++ compiler on our system.
2. Performed some checks to make sure the compiler works.
3. Read our `CMakeLists.txt` file.
4. Generated the native build files in the current directory (`/build`).

If you now look inside your `build` directory, you'll find the generated files.  The files that were generated will depend on your environment.  On Linux, you may have gotten a `Makefile`. On Windows, if you have Visual Studio installed, you may have gotten a `.sln` file and several `.vcxproj` files.


You can check the contents of the directory using your operating system's UI, or through the terminal using the `ls` command, or `dir` on Windows:


```c++
//<ti>
ls
```


On my environment, CMake generated a Ninja project by default, but your output may be different:


```c++
//<o>
CMakeCache.txt  CMakeFiles  build.ninja  cmake_install.cmake
```


We'll learn more about what these other files are for later in the course, and will learn how to configure generation options in general.  For now, we have successfully configured our project, and can move on to building it.


<Pw>


## Building the Project


Now that we have a native build system, we can use it to compile and link our code. We _**could**_ use the native tool directly - for example, we could use `ninja` or `make` to process the generated file, or open the generated Visual Studio solution and use the UI to build the project.


However, the modern CMake approach is to use a universal build command.  We can do this by passing the `--build` flag to `cmake`, followed by the location of our build files.  From the same `build` directory, our command would look like the following.  Note that there is a space followed by a `.` at the end of this command:


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


The `--build` flag tells CMake to invoke the underlying native build tool. The `.` argument specifies that the project should be built within the current directory we're using in our terminal, which should be `/build`.


This command is completely portable. It will call `make` if it generated a Makefile, `ninja` if it generated Ninja files, or `MSBuild` if it generated a Visual Studio solution.


You will see the output from your build system as it builds the targets, which is often going to involve 4 actions:

1. `Greeter.cpp` was compiled into an object file.
2. The object file was archived into the static library `libGreeter.a`.
3. `main.cpp` was compiled into an object file.
4. The main object file was linked with `libGreeter.a` to create the final executable, `GreeterApp`.

Our `GreeterApp` executable should now exist inside the `build` directory.


<Aside>


### The Configure and Build Steps


The two steps we just performed are foundational to understanding how CMake works:

- The **configure** step, which uses the `cmake` command, generates a project based on the contents of our `CMakeLists.txt` file
- The **build** step, which uses the `cmake` command with the `--build` argument, takes that project and compiles it into our final program

The distinction between these two steps, and what happens in each, will come up again and again when learning and using CMake, so it's worth noting their importance early


</Aside>


<Aside>


### IDE Workflow


If you open the `Greeter` folder directly in an IDE like Visual Studio or VS Code (with the CMake Tools extension), the IDE will handle these two steps for you.


When the project is opened, the IDE automatically runs the **configure** step in the background. Then, when you click the "Build" button, the IDE executes the **build** step, effectively running `cmake --build .` for you.


While the IDE workflow is convenient for development, it's important to understand the two-step configure/build process happening under the hood, as you will use these command-line tools for any automated scripting.


</Aside>


## Running and Verifying the Program Output


Our executable has been built and is waiting for us in the `build` directory. Let's run it.


Remember, the executable is in your current directory so you may need to use `./` to tell the shell to run the program from the current location.


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


On Windows, you may also need to add the `.exe` extension:


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


In either case, you should see the expected output from our program, proving that our executable was built and linked with our library correctly.


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


Congratulations! You have successfully configured, built, and run your first CMake project.


## Rebuilding the Project


We don't build our project only once.  We will want to update our code, and generate new builds.  Let's explore what happens when we do this.


The first thing to note is that our build system is generally going to be smart enough to not rebuild things that we haven't changed.  If we change nothing at all and run our build command again, it's likely not going to take any action:


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


```c++
//<o>
ninja: no work to do.
```


Similarly, if we have changed some files, it's only going to rebuild the parts of our project that will be affected by those changes.  For example, let's update `main.cpp` and rerun `cmake --build .`:


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


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

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


</CodeFile>


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


Our static library has not changed, so our build system likely didn't need to rebuild it.  From our previous four-step compilation process, only step 3 (compiling `main.cpp` to an object file) and step 4 (linking with the existing library to create our new executable) were necessary.


### Updating `CMakeLists.txt`


Finally, what happens if we update `CMakeLists.txt`?  Let's try that, by renaming our executable target from `GreeterApp` to `GreeterApp2`:


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


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

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

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


</CodeFile>


This situation is one of the reasons we prefer the the `cmake --build .` approach over using the generated files directly with a command like `make` or `ninja`.


Before invoking the underlying build system, the `cmake` command will first check if our `CMakeLists.txt` file has been updated, meaning the project files that the build system would use (like `Makefile` or `build.ninja`) will be out of date.


That is indeed the case so, before invoking the underlying build system, CMake will first re-run the configure step to generate new project files that incorporate our changes:


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


```c++
//<o>
Re-running CMake...-- Configuring done (0.1s)
-- Generating done (0.0s)
-- Build files have been written to: D:/Projects/cmake/build

Linking CXX executable GreeterApp2.exe
```


In this case, our build system also detected that no source code changes were made, so it didn't need to recompile anything.  It simply needed to link our previously created object files to generate an executable with the new "GreeterApp2" name.


## Clean Builds


When we run `cmake --build .`, the command does **not** delete any existing content in the `/build` folder.  This is usually desirable as, in more complex projects, the content in that folder can take several minutes to generate.  That's a long time to wait when we're experimenting with small, incremental changes to our code and want to see their effects.


CMake and build systems try to keep build times down by not recompiling things they don't think need to be recompiled.  They will instead reuse what's already in the build folder from some previous build.  However, they're not perfect at keeping track of this - sometimes, they don't realise that they're trying to use something that is stale and needs to be regenerated.


By deleting all the content in our build folder, we force CMake and the build system to generate a fresh copy of everything the next time we run the configure and build steps.  This is coloqually referred to as performing a **clean build** and is usually the first troubleshooting step we perform when something isn't working and we don't know why.


## Troubleshooting Initial CMake Errors


Things don't always go so smoothly. You're likely to run into a few common issues using CMake for the first time. Here's how to diagnose and fix the most common problems.


### Delete the `/build` Directory


As mentioned above, one of the first things we should try is performing a **clean build** by deleting everything in the `/build` folder.


Once it's cleaned out, we can quickly regenerate a fresh copy of only the stuff we need by rerunning the configure step (`cmake ..`) and build step (`cmake --build .`)


### Compiler Not Found


During the configure step (`cmake ..`), you might see an error like this:


```c++
//<oe>
-- The CXX compiler identification is unknown
...
CMake Error at CMakeLists.txt:2 (project):
  No CMAKE_C_COMPILER could be found.
  No CMAKE_CXX_COMPILER could be found.
```


This means CMake searched all the standard places and could not find a C++ compiler.  There are a few potential causes of this.


**You haven't installed a compiler**: You need to ensure a C++ toolchain is installed and working correctly on your environment.  We covered how to do this in our <InlineLessonPromo url="cmake/cpp-build-process" title="Building C++ Programs" description="Before working with CMake, it's useful to understand the tools it orchestrates. This lesson guides you through setting up a C++ toolchain.">introductory lesson</InlineLessonPromo>.


**You're using a different environment**: If you've verified you have a working toolchain and have been able to compile programs using it, you need to ensure you're running `cmake` from that same environment.


For example, if you've been using the "Developer Command Prompt for VS2022" or the MSYS2 UCRT terminal on Windows to compile your programs, you should use that same environment for your `cmake` commands.


**You've just installed it**: If you just installed a compiler, you may need to _**close and reopen your terminal**_ for the changes to take effect.


### Syntax Problems in `CMakeLists.txt`


CMake will also complain if there are typos or errors in your `CMakeLists.txt` file.  For example:


```c++
//<oe>
CMake Error at CMakeLists.txt:10 (target_link_librarie):
  Unknown CMake command "target_link_librarie".
```


This is usually an easy fix. The error message is usually clear:

- It tells you the file and line number (`CMakeLists.txt:10`).
- It tells you what it thinks the problem is (`Unknown CMake command`).

In this case, we simply misspelled `target_link_libraries()`.  CMake commands are case-insensitive, but for clarity and convention, you should stick to the lowercase `command_name()` style.


## Summary


In this lesson, we bridged the gap between writing a `CMakeLists.txt` and having a working program. We've mastered the fundamental two-step workflow that lies at the heart of every CMake project.

- **Configure (****`cmake ..`****)**: This first step reads your `CMakeLists.txt` and generates a native build system in a separate `build` directory. Always use out-of-source builds!
- **Build (****`cmake --build .`****)**: This second step invokes the native build tool to compile your sources, link your libraries, and create your final targets. This command is portable and should be your default way to build.
- **Run**: The final executables are created inside the `build` directory, ready to be run and tested.
- **Troubleshooting**: Most initial problems stem from a faulty build folder (fixed by performing a clean build), misconfigured environment (compiler not found), or simple typos in the `CMakeLists.txt` file.

You now have a complete, end-to-end understanding of how to take a simple C++ project from source code to a running executable using CMake.


</Pw>

Added section to emphasise the importance of the Configure and Build phases.  Added note about always running commands from the `/build` directory

Highlighted that there is a `.` in `cmake --build .`

Promoted the clean build advice out of the troubleshooting steps and into a dedicated section

Writing a Basic CMakeLists for a Small Project

Resources

CMake Command-Line Interface

CMake Tutorial - A Basic Starting Point

Build a CMake project in Visual Studio

In-Source Build vs. Out-Of-Source Build

Professional CMake: A Practical Guide

CMake Tutorial EP 1 | Understanding The Basics

A step-by-step guide to building C++ projects with CMake. Learn the `cmake` and `cmake --build` commands, how to run your program, and how to troubleshoot common errors like 'compiler not found' or syntax mistakes in your CMakeLists.txt.

Building and Running CMake Projects

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

Managing C++ Projects Using CMake