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 the last lesson, we learned to treat CMake targets as self-contained objects, each with its own set of properties. We saw how to attach information like include paths and compile definitions to a specific library or executable.


But a project is more than a collection of isolated components; it's a network of dependencies. What happens when one target needs to use another? How does our application automatically know where to find the headers for the library it uses? Manually adding every library's include path to every application that uses it would be a repetitive and error-prone nightmare.


Thankfully, this is something that CMake can help with.  We will fully explore the `target_link_libraries()` command, seeing how it does much more than just link. We'll also cover the `PUBLIC`, `PRIVATE`, and `INTERFACE` keywords, which control how usage requirements automatically flow from a library to its consumers, creating a robust and self-managing build system.


## Understanding CMake Targets


A **target** is any output of the build system. The most common targets are executables and libraries, but they can also be custom commands for things like generating documentation, which we'll cover later. Everything in a modern CMake project revolves around defining targets and manipulating their properties.


We've already seen the commands for creating targets: `add_executable()` and `add_library()`. Let's review `add_executable()` quickly, and then expand upon the `add_library()` command.


## Executable Targets using `add_executable()`


This is the most straightforward target type. It represents a standalone program that can be run.


```c++
#<cmake>
add_executable(MyApp src/main.cpp src/app.cpp)
```


This creates a target named `MyApp` that, when built, will produce an executable file (e.g., `MyApp.exe` on Windows or `MyApp` on Linux).


## Static and Shared Library Targets using `add_library()`


The `add_library()` command can create two kinds of "real" libraries that are built from source files, as well as a more abstract "interface" library.  Let's introduce all three.


### Static Libraries


To specify our library should be static, we add the `STATIC` keyword. The library's compiled code is then copied into any target that links against it at build time:


```c++
#<cmake>
# Creates libPhysics.a or Physics.lib
add_library(Physics STATIC src/dynamics.cpp src/collision.cpp)
```


If we don't specify the type, CMake will create a `STATIC` library by default:


```c++
#<cmake>
# This will create a STATIC library by default
add_library(Physics src/dynamics.cpp src/collision.cpp)
```


This default behavior is is something we can change, and it is quite an important setting.  We'll revisit this topic later in the chapter to explain how we can change this, and why we'd want to.


### Shared/Dynamic Libraries


These are created with the `SHARED` keyword. The library is a separate file (`.so` or `.dll`) that is loaded by the operating system at runtime:


```c++
#<cmake>
# Creates libRenderer.so or Renderer.dll
add_library(Renderer SHARED src/window.cpp src/shader.cpp)
```


Whilst this will build a shared library, it may not automatically place that library in a location where our executable can find it.  We'll cover how to automate this process in more detail later in the course.


<Pw>


## Interface Library Targets


An interface is a "virtual" target type that doesn't compile any source code and doesn't produce a library file on disk. So, what is it for?


An `INTERFACE` library is a way to bundle together **usage requirements**. It's a target that exists only to have properties attached to it, which can then be inherited by other targets that "link" to it.


```c++
#<cmake>
add_library(MyHeaderOnlyLib INTERFACE)
```


We'll see practical examples soon, but an `INTERFACE` library is perfect for two common scenarios:

1. **Header-Only Libraries**: A library that consists only of header files and has no source to compile. However, any target that uses the library still needs to know where those header files are located. An `INTERFACE` library is the perfect way to model this relationship and share that information.  We'll walk through a practical example of this later in the lesson.
2. **Grouping Properties**: You can create an `INTERFACE` library to represent a set of common properties, like a group of compiler settings. Any target that "links" to this interface library can inherit those properties.  We'll walk through an example of this in the next lesson.

This is a little abstract so don't worry if interface libraries don't make much sense yet.  We'll explain what "usage requirements" and "inheriting properties" means through the rest of this lesson, and see several practical examples of `INTERFACE` libraries through the rest of the chapter.


## The `PUBLIC`, `PRIVATE`, and `INTERFACE` Keywords


This is one of the most important concepts in CMake. When we add a property (like an include directory or a compile definition) to a target, we will typically also specify the **visibility** of that property. This tells CMake how the property should propagate to other targets that link to our library.


### Usage Requirements and Properties


When we use a command like `target_include_directories()`, we're setting what CMake conceptually refers to as **usage requirements**.  "If you want to use my library, you'll need to set these include directories".


From a lower level technical perspective, what we're doing is setting specific **properties** on that target.


The benefit of CMake is that it can automatically copy these usage requirements (by copying the underlying properties) to the targets that need them.  For example, let's consider two commands in our current CMake configuration

- `GreeterLib` uses `target_include_directories()` to specify where its header files are.  This is conceptually setting a usage requirement - "if something wants to use `GreeterLib`, it will need to set these include directories"
- `GreeterApp` uses `target_link_library()` to link to `GreeterLib`.  This is conceptually saying "`GreeterApp` wants to use `GreeterLib`"

CMake, seeing both of these commands, can jump into action and automatically ensure `GreeterApp` does indeed set the include directories it will need to use `GreeterLib`.


### Property Visibility


When we use a command like `target_include_directories()`, we are setting properties on the target.  We have the opportunity to specify the visibility of those properties as either `PUBLIC`, `PRIVATE`, or `INTERFACE`.  Using `PRIVATE`, for example, would look like this:


```c++
#<cmake>
target_include_directories(SomeLibrary PRIVATE
  ${CMAKE_CURRENT_SOURCE_DIR}/src
)
```


We'll cover all three of these options with practical examples in the next section but, from a high level:

- A `PRIVATE` property applies only to `SomeLibrary`
- An `INTERFACE` property applies only to targets that link against `SomeLibrary`
- A `PUBLIC` property applies both to `SomeLibrary` and to targets that link against `SomeLibrary`

Let's cover all three of these with some practical examples.


## Practical Examples


Let's expand on our `Greeter` project to understand these three keywords. Our project currently has two targets: the `GreeterApp` executable and the `GreeterLib` library.


`GreeterApp` depends on `GreeterLib`, and we have already informed CMake about this dependency using the `target_link_libraries()` command:


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


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

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


</CodeFile>


<Img hasTransparency invertible file="cmake-producer-consumer-2.png" alt="Diagram showing the effect of target_link_libraries" width="1400" height="544" blurHash="L46[2Ht7fQay~qofofay00WBayj[" />


### Practical Example: `PRIVATE`


Imagine `GreeterLib` has an internal helper header, `src/InternalDetails.h`, that is used by our `src/Greeter.cpp`:


<CodeFile path="greeter/src/InternalDetails.h">


```c++
#pragma once

namespace InternalDetails {
  inline const std::string Name{"the modular Greeting Library"};
}
```


</CodeFile>


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


```c++
#include <greeter/Greeter.h>

// We should #include "InternalDetails.h" as the header 
// is in the same directory as this source file.  We'll
// use <> as we want the preprocessor to look only in the
// search paths defined by CMake for this contrived example
#include <InternalDetails.h>//<h>

std::string get_greeting() {
  return "Hello from " + InternalDetails::Name + "!";//<h>
}
```


</CodeFile>


To make this `#include` directive work, we need to add the `/src` directory to `GreeterLib`'s include directories.


However, `GreeterApp`, and any other target that might use our library in the future, does **not** need to know or care about this internal implementation detail.


As such, we'd make this `target_include_directories()` command `PRIVATE`. A `PRIVATE` property applies _**only**_ to the target it's set on. It is an internal implementation detail and is never seen by any target that uses our library:


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


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

add_library(GreeterLib src/Greeter.cpp)

# The 'include' directory continues to be public
# Consumers need to know about these header files
target_include_directories(GreeterLib PUBLIC
  "${CMAKE_CURRENT_SOURCE_DIR}/include"
)

# The 'src' directory is a PRIVATE implementation detail.
# Only GreeterLib's own source files need this path.
target_include_directories(GreeterLib PRIVATE #<h>
  ${CMAKE_CURRENT_SOURCE_DIR}/src #<h>
) #<h>
```


</CodeFile>


When we link `GreeterApp` to `GreeterLib`, `GreeterApp` will _**not**_ have `greeter/src` directory added to its include paths, because that was a `PRIVATE` detail. This is exactly what we want - we're encapsulating `GreeterLib`'s internal build requirements, without those requirements unnecessarily affecting other components.


### Practical Example: `INTERFACE`


An `INTERFACE` property applies _**only**_ to consumers of a target. The target itself doesn't use the property when it's being built.  This is the perfect keyword for header-only libraries.


Let's add a tiny header-only library to our project that can return the current day.  We'll follow the "namespaced include" structure of our `greeter` directory.  In this case, our library is just a single header file - we don't need a `/src` folder:


<CodeFile path="date/include/date/Today.h">


```c++
#pragma once

#include <string>
#include <chrono>
#include <format>

namespace Date {
inline std::string Today() {
  return std::format(
    "{:%A}", std::chrono::system_clock::now()
  );
}
}
```


</CodeFile>


As usual, we'll create a `CMakeLists.txt` file for our library, making it easy to integrate into our build.  Any consumer of our `Date` library will need this `date/include` directory added to its search paths.


However, the `Date` target itself does not need this property.  It's a header-only library, so it doesn't get directly compiled - all compiling is done by the targets that `#include` our header.  As such, it doesn't need include directories, only the targets that use it do, so we'll mark these include directories as an `INTERFACE`.


Additionally, our library requires C++20 for `std::format()`, so any target that uses our library will need to support that standard.  Let's express that requirement using `target_compile_features()`.  Again, we express this requirement with `INTERFACE` visibility, because our `Date` library doesn't get compiled directly, so it doesn't require this standard internally.  


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


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

# No source files, so this is an INTERFACE library
add_library(Date INTERFACE)

# The include directory is an INTERFACE property.
# Date itself doesn't need to compile anything
# However, anyone who uses it needs this path.
target_include_directories(Date INTERFACE
  "${CMAKE_CURRENT_SOURCE_DIR}/include"
)

# We're using std::format, which was added in C++20
# Anyone linking against us will need to support that
target_compile_features(Date INTERFACE cxx_std_20)
```


</CodeFile>


We can add this new `CMakeLists.txt` file to our build in the usual way, with an `add_subdirectory()` command:


<CodeFile path="CMakeLists.txt">


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

project(Greeter VERSION "1.0")

add_subdirectory(greeter)
add_subdirectory(app)
add_subdirectory(date)#<h>
```


</CodeFile>


Now, any target that needs to use our library can link against it using `target_link_libraries()` as usual:


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


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

add_executable(GreeterApp src/main.cpp)

target_link_libraries(GreeterApp GreeterLib)
target_link_libraries(GreeterApp Date)#<h>
```


</CodeFile>


Given that our `Date` command used the `INTERFACE` visibility when setting `/date/include` as an include directory, our `GreeterApp` target that linked against it has also inherited that include directory:


```c++
#include <iostream>
#include <greeter/Greeter.h>
#include <date/Today.h>//<h>

int main() {
  std::cout << get_greeting();
  std::cout << "\nHappy " << Date::Today();//<h>
  return 0;
}
```


If we build everything and run `GreeterApp` or `GreeterApp.exe` (or `Greeter` / `Greeter.exe` if you updated the `OUTPUT_NAME` property in the previous lesson) we should see everything working:


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


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


```c++
//<o>
Hello from the modular Greeting Library!
Happy Thursday
```


### Practical Example: `PUBLIC`


A `PUBLIC` property is simply a combination of `PRIVATE` and `INTERFACE`. The property is applied to the target itself _**and**_ it's propagated to any consumers.


This is the most common keyword you'll use for a typical library's public headers. The library's own source files usually needs to `#include` its own public headers, and so do any other targets that use the library.


We're already using a `PUBLIC` property for our library's `/greeter/include` directory:


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


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

add_library(GreeterLib src/Greeter.cpp)

# The 'include' directory contains public headers.
# GreeterLib needs it for its own compilation, AND
# GreeterApp needs it to use the library.
target_include_directories(GreeterLib PUBLIC #<h>
  "${CMAKE_CURRENT_SOURCE_DIR}/include" #<h>
) #<h>
```


</CodeFile>


This path is required by the `GreeterLib` target itself for the `#include` directive in `greeter/src/Greeter.cpp`.  As such, we shouldn't make it an `INTERFACE`.


Any other target that wants to use this library, such as `GreeterApp`, will also need to know about this include directory, so it shouldn't be `PRIVATE` either.


The property is needed both by the target itself, and by targets that depend on it, so we declared that property as `PUBLIC`.


As a consequence, when our `GreeterApp` target linked against `GreeterLib` using `target_link_libraries(GreeterApp GreeterLib)`, it inherited that include directory automatically.


That is what allowed the highlighted `#include` directive to work:


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


```c++
#include <iostream>
#include <greeter/Greeter.h>//<h>
#include <date/Today.h>

int main() {
  std::cout << get_greeting();
  std::cout << "\nHappy " << Date::Today();
  return 0;
}
```


</CodeFile>


## Summary


This lesson expanded on the core of CMake, covering how it establishes the relationship between our targets as a web of dependencies, and then automatically manages the indirect links in that web.


**Four Target Types**: Executables, `STATIC` libraries, `SHARED` libraries, and `INTERFACE` libraries.


**The Three Keywords**: This is the most important concept.

- `PRIVATE`: For internal implementation details. Does not propagate to consumers.
- `INTERFACE`: For consumers only. Used by the target that links _to_ you.
- `PUBLIC`: For both. Used by you _and_ your consumers.

<Preview>


### Indirect Relationships and the Dependency Graph


We've seen how properties flow from a library to its direct consumer. But what happens when these dependencies are chained?


If our `GreeterApp` links to `GreeterLib`, and `GreeterLib` in turn links to a `Logging` library, does that mean properties on the `Logging` library should be inherited by `GreeterApp`?  And if so, how do we make that happen?


The answer lies in understanding that CMake doesn't just link files; it builds a **dependency graph.**


In the next lesson, we will explore this concept. We'll see how `target_link_libraries()` does more than just specify a link - it defines a relationship in this graph. We'll learn how the `PUBLIC` and `PRIVATE` keywords can also be applied to the link itself, controlling how usage requirements flow through these indirect, or **transitive**, dependencies.


</Preview>


</Pw>

Fixed error where `Greeter.cpp` was mislabeled `Greeter.h`

`target_link_libraries` Documentation

Creating Targets

It's Time To Do CMake Right

Embracing Modern CMake - Stephen Kelly

CMake: PUBLIC vs INTERFACE vs PRIVATE

Modern CMake is like inheritance

Master Modern CMake by understanding its core concept: targets. This guide covers target types (executable, static, shared, interface) and the PUBLIC, PRIVATE, and INTERFACE keywords that enable transitive dependency management.

Relationships Between Targets: The Core of Modern CMake

Executable Targets using `add_executable()`

Static and Shared Library Targets using `add_library()`

The `PUBLIC`, `PRIVATE`, and `INTERFACE` Keywords

Relationships Between Targets

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

Managing C++ Projects Using CMake