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

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

Building C++ Programs

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

The Compilation Pipeline

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

Object Files and the Linking Process

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

Static and Shared Libraries

The C++ Build Process

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

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

Organizing a C++ Project

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

Managing Libraries and Dependencies

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

Automated Build Systems and Their Limitations

Project Structure and Dependency Management

Setting up CMake and creating your first project

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

Why CMake?

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

Setting Up a CMake Environment

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

Writing a CMakeLists File

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

Building and Running CMake Projects

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

CMake Project Structure and Subdirectories

Introducing CMake

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

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

CMake Variables and Logging

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

The CMake Cache

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

CMake Commands, Arguments, and Lists

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

CMake Conditionals and Loops

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

Working with the File System

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

Modularizing CMake Code

CMake Language and Fundamentals

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

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

Target Properties

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

Relationships Between Targets

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

Indirect Relationships and the Dependency Graph

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

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

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

Using Shared Libraries

Targets and Dependencies

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

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

Build Configurations (Debug, Release, etc.)

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

Cross-Platform Configurations

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

Handling Different Architectures

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

Cross-Compilation and Toolchain Files

Platforms and Build Configurations

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

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

Finding Dependencies using `find_package()`

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

Creating a Consumable Package

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

Using Installed Packages

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

Fetching External Dependencies

Creating and Consuming Packages

Integrating the vcpkg and Conan package managers to handle external dependencies

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

Integrating CMake and vcpkg

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

vcpkg Commands and Versioning

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

Cross-Compiling with vcpkg

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

Using Conan with CMake

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

Cross-Compilation with Conan

Package Managers

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

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

CMake Presets

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

User Presets and Inheritance

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

Environment Variables and Conditional Presets

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

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

Generator Expressions and Conditional Logic

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

Integrating Tools with `add_custom_command()`

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

Generating Files with Protobuf and `add_custom_command()`

Custom Commands

An introduction to automating common workflow chores by creating custom targets

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

Custom Targets and Build Utilities

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

Using Clang-Format

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

Using File Sets

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

Generating Documentation with Doxygen

Custom Targets

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

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

Automated Testing and CTest

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

Integrating GoogleTest with CMake

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

Assertions and Parameterized Tests

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

Dependency Injection and Mocking

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

Testing Executables

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

Managing a Test Suite

Automated Testing

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

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

Using AddressSanitizer (ASan)

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

Using Google Benchmark

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

Using Clang-Tidy

Automated Analysis

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

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

Source Control with Git

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

Build Servers and Continuous Integration

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

Packaging with CPack

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

Packaging with GitHub Actions

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

Creating Installers with CPack and GitHub Actions

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

Deployment with GitHub Releases

Continuous Integration and Packaging

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

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

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

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

The Full Build Pipeline

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

Complete CMake Language Mastery

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

Advanced Target Management

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

In-Depth Dependency Management

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

Total Workflow Automation

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

End-to-End CI/CD and Deployment

What You'll Learn

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

Intro to C++ Programming

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

New to Programming?

Managing C++ Projects Using CMake

So far, we've built our projects using only the source code we've written ourselves. But the power of C++ comes from its vast ecosystem of third-party libraries. We don't want to reinvent the wheel for every task.


But how do we incorporate a third party library?  This will be the focus of this chapter.  By the end of this chapter, we'll unlock the ability for our projects to automatically download the libraries we need from the internet.


However, in this first lesson, we'll focus on libraries that are already installed on our machine, and CMake just needs to find them.  This is the job of the `find_package()` command.  We'll learn how it works, explore its two modes of operation, and master the modern, target-based approach that makes using external libraries clean and simple.


## The `find_package()` Command


When you call `find_package(SomeLib)`, CMake embarks on a search to find `SomeLib`. It has two distinct strategies for finding the library, which it tries in order.


### Module Mode (The Old Way)


First, CMake checks if it has a special script called `FindSomeLib.cmake`. It looks in two places:

1. Its own installation directory, which contains `Find<...>.cmake` modules for many libraries that are popular in the C++ world.  This includes the popular Boost libraries, which we'll use in this lesson.
2. Any directories listed in the `CMAKE_MODULE_PATH` variable.  This means that if CMake doesn't have a `FindSomeLib.cmake` script itself, we can help it out and write our own.  That script will then be used when we use the command `find_package(SomeLib)`.

A `Find` script is an active, searching script. It runs a series of commands (`find_path()`, `find_library()`) to hunt for the library's header files and binary files in standard system locations. If it's successful, it sets a series of variables for you to use:

- `SomeLib_FOUND`: Set to true if the library was found.
- `SomeLib_INCLUDE_DIRS`: A path to the library's include directories.
- `SomeLib_LIBRARIES`: A path to the library files to link against.

You would then use these variables to configure your target in the normal way, using `target_include_directories()` and `target_link_Libraries()`:


```c++
//<cmake>
target_include_directories(MyApp PRIVATE ${SomeLib_INCLUDE_DIRS})
target_link_libraries(MyApp PRIVATE ${SomeLib_LIBRARIES})
```


This pattern is still common in older projects, but it's considered legacy. It's verbose and requires you to manually plumb variables into your targets.


### Config Mode (The Modern Way)


If CMake can't find a `FindSomeLib.cmake` module, it switches to **Config mode**. This is the modern, preferred approach.  We can also explicitly ask CMake to skip the module mode search and jump straight to config mode by passing the `CONFIG` keyword to `find_package()`.  We'll use this in our example later in the lesson.


In config mode, CMake searches for a file that the library itself installed, trying names like `SomeLibConfig.cmake` and `somelib-config.cmake`. When this file is found and executed, it doesn't just set variables - it defines `IMPORTED` targets.  Like any CMake target, these have all the power and flexibility we've seen in previous chapters.


As we learned in our lesson on <InlineLessonPromo slug="cmake/cmake-property-groups-aliases-and-imports">abstract targets</InlineLessonPromo>, an `IMPORTED` target is a CMake target that represents a pre-existing binary on disk. The `Config.cmake` file tells CMake: "Here is a target called `SomeLib`. I've already attached all its properties, like its include directories and link dependencies."


This means you don't need to juggle variables. You just link to the provided target, and all the usage requirements are propagated automatically.


## A Practical Example with Boost


Let's see this in action by adding a Boost library to our build.  Boost has over 160 components covering a huge range of utility and it is the most used third-party library in the C++ world.


### Installing Boost


Remember, `find_package()` can only find what's already on our disk.  So, lets start by installling the Boost development libraries on our system

- **Windows (MSVC):** Download the pre-built binaries from the [official Boost website](https://www.boost.org/users/download/). Make sure to get a version that matches your compiler (e.g., MSVC 14.3 for Visual Studio 2022).
- **Windows (MSYS2 UCRT64)**: `pacman -S mingw-w64-ucrt-x86_64-boost`
- **macOS (Homebrew):** `brew install boost`
- **Linux (Ubuntu/Debian):** `sudo apt-get install libboost-all-dev`

### The `CMakeLists.txt`


Let's update our GreeterApp to uses Boost's `program_options` library.  This makes it easier for our program to accept options on the command line.  In much the same way that `cmake` accepts arguments such as `--config Debug` or `--build .`, we'll update our `GreeterApp` to accept an argument like `--greeting Howdy`:


```c++
//<ti>
./app/GreeterApp --greeting Howdy
```


This `greeting` argument will affect our program's behaviour:


```c++
//<o>
Howdy from the GreeterApp
```


The code to make this happen is included in `main.cpp` below but, for this course, we'll focus on the `CMakeLists.txt` file rather than how to use a Boost library.  Let's start by adding a `find_package()` command:


<CodeViewer>


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


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

add_executable(GreeterApp src/main.cpp)

# We don't need GreeterLib for now
target_link_libraries(GreeterApp GreeterLib) #<d>

# Find the Boost libraries
find_package(Boost REQUIRED COMPONENTS program_options CONFIG)#<h>
```


</CodeFile>


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


```c++
#include <boost/program_options.hpp>
#include <iostream>
#include <string>

int main(int argc, char* argv[]) {
  std::string greeting;
  boost::program_options::options_description desc;
  desc.add_options()(
    "greeting",
    boost::program_options::value<std::string>(&greeting)
  );

  boost::program_options::variables_map vm;
  boost::program_options::store(
    boost::program_options::parse_command_line(
      argc, argv, desc
    ),
    vm
  );
  
  boost::program_options::notify(vm);

  if (vm.count("greeting")) {
    std::cout << greeting << " from the GreeterApp";
  } else {
    std::cout << "No --greeting argument provided";
  }

  return 0;
}
```


</CodeFile>


</CodeViewer>


Let's break down the `find_package()` command:

- `find_package(Boost ...)`: We're looking for the Boost libraries.
- `REQUIRED`: This keyword makes the search critical. If Boost is not found, CMake will stop with a fatal error. If you omit this, the script will proceed, but Boost won't be available.  We'll see how to deal with `find_package()` failures later in the lesson.
- `COMPONENTS program_options`: Many packages, including Boost, have a range of components that we can include.  In this case, we're requesting the `program_options` component.
- `CONFIG`: This asks CMake to skip the legacy "module mode" search and jump straight to the modern "config mode" described above.

We've now found the library, but we're not using it yet.  Before our build works, our `GreeterApp` target still needs to link to the library, and have its search paths updated to make its `#include <boost/program_options.hpp>` directive work.  We'll do that in the next section.


<Error>


### Policy CMP0167 is not set


The `find_package()` command first attempts to find the requested package using the legacy "module mode" and, if that fails, it tries the "config mode".  This is the default behavior:


```c++
# Find the Boost libraries using module mode (legacy)
# If module mode fails, try config mode (modern)
find_package(Boost REQUIRED COMPONENTS program_options)
```


CMake includes a `FindBoost.cmake` script, so the module mode search will find what we're looking for.  However, this legacy approach would emit a warning in our current `cmake_minimum_required()` version of `3.16`, and would be an error if we bumped this to `3.30` or later.


We can skip the module mode search and clarify we only want to use Boost's official CMake configuration scripts by adding the `CONFIG` argument:


```c++
# Skip the module mode search
# Only search for Boost using config mode (modern)
find_package(Boost REQUIRED COMPONENTS program_options CONFIG)#<h>
```


If we want to only use the legacy module mode, we can pass the `MODULE` argument instead.  If the module mode search fails, this will result in an error if we used the `REQUIRED` argument, and a warning otherwise:


```c++
# Find the Boost libraries using module mode (legacy)
# If this fails, emit an error
find_package(Boost REQUIRED COMPONENTS program_options MODULE)
```


</Error>


<Pw>


## Legacy Linking Using Variables


After the `find_package()` call, the `FindBoost.cmake` module has set several variables for us. We could use the legacy pattern:


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

add_executable(GreeterApp src/main.cpp)

find_package(Boost REQUIRED COMPONENTS program_options)

# LEGACY: Manually use the variables
target_include_directories(GreeterApp PRIVATE#<h>
  ${Boost_INCLUDE_DIRS}#<h>
)#<h>

target_link_libraries(GreeterApp PRIVATE#<h>
  ${Boost_LIBRARIES}#<h>
)#<h>
```


This works, but it's not ideal. We have to know the specific variable names that the library's CMake file sets.  In this case, it's `Boost_INCLUDE_DIRS` and `Boost_LIBRARIES`, but a different library might set different variables.


## Modern Linking Using Imported Targets


Fortunately, Boost has been updated to also provide modern, imported targets. A common convention is for a `find_package()` result to provide an alias for the target in the format `Package::Component`.


Boost adopts this convention too, so our target will be available as `Boost::program_options`.  We link to it like any other target:


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


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

add_executable(GreeterApp src/main.cpp)

find_package(Boost REQUIRED COMPONENTS program_options)

target_include_directories(GreeterApp PRIVATE#<d>
  ${Boost_INCLUDE_DIRS}#<d>
)#<d>

# MODERN: Link to the IMPORTED target
target_link_libraries(GreeterApp PRIVATE
  ${Boost_LIBRARIES}#<d>
  Boost::program_options#<h>
)
```


</CodeFile>


As usual with a well configured target, this `target_link_libraries()` command will hook up everything we need:

1. It links our `GreeterApp` to the actual Boost `program_options` library file.
2. It automatically adds the necessary include directories to our target because they are an `INTERFACE` property of the `Boost::program_options` imported target.
3. It handles any other transitive dependencies.

Let's build and run our program:


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


```c++
//<ti>
./app/GreeterApp --greeting Howdy
```


```c++
//<o>
Howdy from the GreeterApp
```


## Optional Packages


What happens when `find_package()` cannot find what we requested?  If we set the package as `REQUIRED`, our script will fail with an error:


```c++
#<cmake>
find_package(SomeLib REQUIRED)
```


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


```c++
//<o>
CMake Error at app/CMakeLists.txt:8 (find_package):
  By not providing "FindSomeLib.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "SomeLib", but
  CMake did not find one.

  Could not find a package configuration file provided by "SomeLib" with any
  of the following names:

    SomeLibConfig.cmake
    somelib-config.cmake

-- Configuring incomplete, errors occurred!
```


Our error output is likely to document CMake's attempt to find the package in both module mode and config mode, along with some suggestions on how we might help it.  We'll cover how to help CMake find the packages we're looking for later in the chapter.


In most cases, failing with an error is what should happen when an important library isn't found.


However, in some circumstances, it may be acceptable that CMake fails to find a package, so that shouldn't break our build.  There are two main reasons why failing to find a package is acceptable:

- We can recover from the package being missing.  If the developer doesn't have it, our script might be able to find the package in some other way, download it from the internet, or build it from source.
- The package might be used to support an optional feature in our program, or an internal development tool such as a code formatter.  If a developer doesn't want to use that feature or tool, we shouldn't require them to install a package they don't need.

We'll see examples of both of these use cases later in the course.  


For now, to prevent CMake from erroring on `find_package()` failures, we remove the `REQUIRED` keyword:


```c++
#<cmake>
find_package(SomeLib REQUIRED)#<d>
find_package(SomeLib)#<h>
```


This will downgrade our error to a warning, and allow our script to continue.  We can suppress the warning by adding the `QUIET` keyword, if preferred:


```c++
#<cmake>
find_package(SomeLib QUIET)
```


The `find_package(PackageName)` command will set a `PackageName_FOUND` variable if it found our package.  We can use this to react as needed to success or failures:


```c++
#<cmake>
if(NOT SomeLib_FOUND)
  message(STATUS "SomeLib was not found, but I can continue")
  # ...
endif()
```


```c++
//<o>
-- SomeLib was not found, but I can continue
```


We'll learn some useful approaches to dealing with these optional `find_package()` failures soon, including having CMake just download the missing package from the internet.


## Setting the Required Version


We can specify the **minimum** version of the library that our program requires by providing it as an argument to `find_package()` after the library name:


```c++
#<cmake>
find_package(
  Boost
  1.5#<h>
  REQUIRED
  COMPONENTS program_options
  CONFIG
)
```


We can require an **exact** version of a library by adding the `EXACT` keyword:


```c++
#<cmake>
find_package(
  Boost
  1.5 EXACT#<h>
  REQUIRED
  COMPONENTS program_options
  CONFIG
)
```


We shouldn't overspecify version requirements unless necessary.  If any version of the library will work, we shouldn't specify a version requirement.  If the feature we need was added in version `1.5` and continues to be available, we should set that as a **minimum** requirement rather than an `EXACT` requirement.


Setting spurious requirements makes our code more difficult to integrate with other projects, especially if those projects have their own version requirements that might conflict with ours.


From CMake 3.19 onwards, we can specify both a minimum and maximum version using the `...` syntax:


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

# ...

find_package(
  Boost
  # Any version from 1.5 to 1.6 (inclusive) is okay
  1.5 ... 1.6 #<h>
  REQUIRED
  COMPONENTS program_options
  CONFIG
)
```


The main use case for this is when the feature we rely on was removed from the library at some point.  In that case, we'd typically add a `<` token to exclude that breaking version from the acceptable range:


```c++
#<cmake>
find_package(
  Boost
  # The feature we need was added in version 1.5
  # It was removed in 2.0
  1.5 ... <2.0 #<h>
  REQUIRED
  COMPONENTS program_options
  CONFIG
)
```


In professional projects, CMake is often combined with a package manager such as vcpkg or Conan.  These integrate seamlessly with the `find_package()` command, making it a lot easier to use, and helping ensure versions are consistent across our team.  We cover package managers in the next chapter.


## Summary


The `find_package()` command is the bridge between your project and the wider C++ ecosystem. By understanding how it works, you can integrate third-party libraries in a clean, portable, and modern way.

- **Two Modes**: `find_package()` can operate in **Module mode** (using a `FindSomeLib.cmake` script) or **Config mode** (using a `SomeLibConfig.cmake` file provided by the library). Config mode is the modern standard.
- **Imported Targets are Preferred**: A modern `find_package()` call provides `IMPORTED` targets (e.g., `SomeLib::Component`).
- **Link to Targets, Not Variables**: Where possible, prefer `target_link_libraries()` over manually using variables like `${Package_LIBRARIES}`. This encapsulates all usage requirements.

</Pw>

Property Groups, Aliases, and Imports

Vendoring and Fetching Dependencies

`find_package()` Command Documentation

CMake Packages

`install()` Command Documentation

Getting Started on Unix-like variants

Getting Started on Windows

It's Time To Do CMake Right - Finding Dependencies

More Modern CMake - Deniz Bahadir

Master CMake's find_package command. This guide covers how to find and use external C++ libraries, the difference between Module and Config mode, and why modern imported targets (e.g., Boost::boost) are the best practice.

Finding Dependencies using `find_package()`

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

Managing C++ Projects Using CMake

Finding Dependencies using find_package()

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

Finding Dependencies using `find_package()`