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 established the core principle of modern CMake: projects are a dependency graph of targets, and usage requirements flow automatically through that graph. We know how to model libraries built from our own source code and even simple header-only dependencies.


However, as projects grow, we encounter new organizational challenges that `STATIC` and `SHARED` libraries alone can't solve:

1. How do we apply a common set of compiler flags to some, but not all, targets without duplicating code?
2. How do we create names for our library targets that prevent naming collisions, especially in large projects?
3. How do we integrate a third-party library that is only available as a pre-compiled binary (`.a` or `.dll`) rather than as source code?

This lesson will introduce three abstract target types that address these problems: `INTERFACE` libraries as property groups, `ALIAS` targets for namespacing, and `IMPORTED` targets for pre-compiled code.


## Grouping Usage Requirements with `INTERFACE` Libraries


We've seen that an `INTERFACE` library is perfect for a header-only dependency. It has no source files and produces no output, but it can have properties like `INTERFACE_INCLUDE_DIRECTORIES` that are passed on to any consumer.


We can take this concept a step further. An `INTERFACE` library can be used as a general-purpose "bag of properties" to group _**any**_ set of usage requirements, not just include directories.


### Practical Example: Enforcing Strict Warnings


A common requirement is to build our internal code with a very strict set of compiler warnings to catch potential bugs early. However, we don't want to force these strict warnings onto the final application or any external consumer of our libraries, as that would be impolite.


We can solve this problem with an `INTERFACE` library. Let's create one in our root `CMakeLists.txt` to represent our project's internal warning policy:


<CodeFile path="CMakeLists.txt">


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

project(Greeter VERSION "1.0")

# Create an INTERFACE target to hold our warning flags
add_library(StrictWarnings INTERFACE) #<h>

# Attach compiler options to this target
target_compile_options(StrictWarnings #<h>
  INTERFACE #<h>
    -Wall #<h>
    -Wextra #<h>
    -Wpedantic #<h>
) #<h>

add_subdirectory(greeter)
add_subdirectory(app)
add_subdirectory(date)
```


</CodeFile>


These `-Wall`, `-Wextra`, and `-Wpedantic` flags are for the GCC and Clang compilers.  If you want to follow along using MSVC, you can use `/Wall` and `/W4` instead, but the flags aren't important right now - we're just using them as examples.  We'll cover compiler options and how to make our `CMakeLists.txt` compatible across multiple compilers later in the course.


For now, we've created a simple target named `StrictWarnings` that doesn't build anything. Its only purpose is to carry the `INTERFACE` property `COMPILE_OPTIONS` with our desired warning flags.


Now, how do we use it our new target? In our `GreeterLib`'s `CMakeLists.txt`, we can simply "link" to this interface target just like we would link it to any other target:


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


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

add_library(GreeterLib src/Greeter.cpp)

target_link_libraries(GreeterLib PRIVATE StrictWarnings) #<h>

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


</CodeFile>


Let's review our use of the `INTERFACE` and `PRIVATE` keywords in this context, as it's important that we're comfortable with the behaviour associated with these fundamental CMake behaviors.


### The `INTERFACE` Keyword in `target_compile_options()`


The entire point of the `StrictWarnings` target is to give other targets something to link against if they want to adopt the `target_compile_options()` we associated with `StrictWarnings`.


For those properties to be inheritable by consumers, we need to use the word `INTERFACE` in our `target_compile_options()` command.  Conceptually, `PUBLIC` could also have resulted in this inheritance behaviour, but it would have meant the properties would also apply to `StrictWarnings` itself.


This would be unnecessary and misleading in this case.  `StrictWarnings` is an `INTERFACE` target, so it doesn't have anything to compile.  The `target_compile_options()` function specifically checks for this and, if the target is an `INTERFACE` library, only `INTERFACE` compiler options can be set.


### The `PRIVATE` Keyword in `target_link_libraries()`


We want the properties we set in `StrictWarnings` to apply to targets that explicitly link against it - `GreeterLib` in this example - but that's where the story should end.  They should **not** propagate further than that.  To implement this, `GreeterLib` declared this direct dependency using `target_link_libraries()`, but the dependency was declared as `PRIVATE`.


This means that, when `GreeterApp` later links to `GreeterLib`, `GreeterApp` will **not** see `GreeterLib`'s dependency on `StrictWarnings`.  As such, `GreeterApp` will not adopt `StrictWarnings` as an indirect dependency, and will **not** inherit those compiler settings.


This perfectly encapsulates an internal development standard. We enforce the policy on our own library without imposing it on its consumers.


<Img hasTransparency invertible file="cmake-no-transitive-dependency.png" alt="Diagram showing the effect of the PRIVATE keyword on transitive dependencies" width="1200" height="457" blurHash="L27nRRWB00Rj_3j[4nWB00j[9Fxu" />


<Pw>


## Creating Namespaced Aliases with `ALIAS` Libraries


An `ALIAS` library creates a second name for an existing target. It's not a copy; it's just a reference. Linking to the original name or the alias is identical.


A common convention in larger projects is to create "namespaced" aliases using the `::` separator. When there are many targets, this convention makes the origin of a target clearer, and helps reduce the probability of naming conflicts.


Let's add an alias for our `GreeterLib`. We still need to use our regular name internally, but if our collection of Greeter targets is being shared for use in a larger project, providing namespaced aliases like `Greeter::Lib` and `Greeter::App` could be appreciated.


In a `CMakeLists.txt`, after defining the original target, we can add an alias like this:


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


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

add_library(GreeterLib src/Greeter.cpp)
add_library(Greeter::Lib ALIAS GreeterLib) #<h>

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


</CodeFile>


Consumers can now refer to our target using whichever name they prefer:


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


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

add_executable(GreeterApp src/main.cpp)

# These two are equivalent
target_link_libraries(GreeterApp GreeterLib)#<d>
target_link_libraries(GreeterApp Greeter::Lib)#<h>
```


</CodeFile>


## Using Pre-Compiled Binaries with `IMPORTED` Libraries


So far, we've only worked with targets built from source files within our project. But many library creators prefer not to share their source code.  They distribute their libraries only in a precompiled form, alongside the header files describing what is in the library.


Handling such a dependency is the job of an `IMPORTED` library. It's a target that represents a binary that already exists on disk. You create the target and then manually set the properties that tell CMake where to find its files.


For example, let's imagine that our `GreeterLib` component is shared as a precompiled binary, rather than the complete source code.  If you want to replice this scenario to follow along, you can find the compiled library in your `/build/greeter` directory, and copy it into a more permanant location in the project, such as `/greeter/lib`.


You can also delete the `/greeter/src` directory, or just pretend it doesn't exist.  Your project directory might look something like this:


```plain text
//<nh>
(project root)/
└─ greeter/
   ├─ include/
   │  └─ greeter/
   │     └─ Greeter.h
   ├─ lib/
   │  └─ libgreeter.a
   └─ CMakeLists.txt
└─ ... (our other directories)
```


We need to update our `greeter/CMakeLists.txt` file to reflect this new situation.  No longer is our build compiling `GreeterLib` from its `/src` directory - instead we need to import the already-compiled file from the `/lib` directory.


Lets take a look at the three changes we need to make, and then we'll walk through them step by step:


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


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

# 1. Change our library to IMPORTED STATIC GLOBAL
add_library(GreeterLib src/Greeter.cpp)#<d>
add_library(GreeterLib IMPORTED STATIC GLOBAL)#<h>

# 2. Change our include directory visibility to INTERFACE
target_include_directories(GreeterLib PUBLIC#<d>
target_include_directories(GreeterLib INTERFACE#<h>
  "${CMAKE_CURRENT_SOURCE_DIR}/include"
)

# 3. Provide the path to our prebuilt binary
set_target_properties(GreeterLib PROPERTIES #<h>
  # This property points to the actual binary file#<h>
  IMPORTED_LOCATION "${CMAKE_CURRENT_SOURCE_DIR}/lib/libgreeter.a" #<h>
)#<h>
```


</CodeFile>


### Step 1: Changing to an `IMPORTED STATIC GLOBAL` Library


Here's what these three keywords do:


**IMPORTED**: Instead of our `add_library()` command providing the list of source files, we now declare that the library is already compiled and only needs to be `IMPORTED` into our build. 


**STATIC**: With `IMPORTED` libraries, we also need to explicitly state whether they are `STATIC` or `SHARED`.  We'll revisit this topic in the next lesson and learn the difference between specifying and omitting the library type within an `add_library()` command.


**GLOBAL**: A side-effect of targets that are defined using the `IMPORTED` keyword is that their scope is restricted to just the `CMakeLists.txt` file in which they are declared. We can change this, and return `GreeterLib` to the global scope it previously had, by adding the `GLOBAL` keyword.  This makes the target accessible to other `CMakeLists.txt` files in our build - most notably, the `/app/CMakeLists.txt` file, where `GreeterApp` declares `GreeterLib` as a dependency.


### Step 2: Changing the Include Directories to `INTERFACE`


Previously, our `target_include_directories()` were declared as `PUBLIC`, as they were required both for `GreeterLib` and anything that consumes it.


With `GreeterLib` now being a precompiled `IMPORTED` library, it doesn't need these header files itself, as it no longer needs to be compiled.  As such, we can restrict their visibility to just consumers by using the `INTERFACE` keyword.


### Step 3: Setting the `IMPORTED_LOCATION` Property


Finally, and most obviously, we need to tell CMake where this precompiled library is on our hard drive.  CMake expects this location to be provided as the `IMPORTED_LOCATION` property on the target.  There is no convenient helper function for this, so we just use the general `set_target_properties()` function to set it:


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


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

add_library(GreeterLib STATIC IMPORTED GLOBAL)

target_include_directories(GreeterLib INTERFACE
  "${CMAKE_CURRENT_SOURCE_DIR}/include"
)

# This is where we attach the physical file locations to
# our abstract target
set_target_properties(GreeterLib PROPERTIES #<h>
  # This property points to the actual binary file#<h>
  IMPORTED_LOCATION "${CMAKE_CURRENT_SOURCE_DIR}/lib/libgreeter.a" #<h>
)#<h>
```


</CodeFile>


### Using the Imported Target


From the perspective of any other target, `GreeterLib` is just another library.  The root `CMakeLists.txt` file continues to import it using `add_subdirectory()`, the `app/CMakeLists.txt` file for our `GreeterApp` target continues to link to it, and nothing in our source code needs to change either.


The `IMPORTED` keyword let us create a simple wrapper for a pre-compiled binary, allowed it to be integrating into our build just like any other target.


After a change like this, it is a good idea to clean out our `/build` directory by deleting everything in there.  This removes old unused files still lurking around from previous builds and, when we next run the configure step, `cmake` will regenerate a fresh copy of just the stuff we need.


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


We can then create a build and run `app/GreeterApp` or `app/GreeterApp.exe` to verify that everything still works after our changes:


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


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


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


## Summary


This lesson introduced advanced target types that allow you to create clean, modular, and robust abstractions for your build logic and dependencies.

- **`INTERFACE`** **Libraries as Property Groups**: Use `INTERFACE` targets to bundle common sets of usage requirements (like compiler flags) that can be applied to other targets.
- **`ALIAS`** **Libraries for Namespacing**: Use `add_library(... ALIAS ...)` to create clean, namespaced `Project::Component` names for your targets. This is a key modern CMake best practice.
- **`IMPORTED`** **Libraries for Binaries**: Use `add_library(... IMPORTED)` to wrap pre-compiled third-party libraries. This creates a proper target that can be integrated into your dependency graph, abstracting away the physical file paths.

By mastering these patterns, you can move beyond simple builds and start designing sophisticated build systems that are a pleasure to work with, even as your projects scale in complexity.


<Preview>


### Build Types, Exporting, and Link Order


We've designed a powerful, modular build system. But we're still missing some key features. How do we manage different build configurations like `Debug` and `Release`? And how do we package our library so that other CMake projects can use it easily with `find_package()`?


In the next lesson, we will tackle these questions. We'll explore CMake's built-in support for build types, learn how to export our targets to create a relocatable package, and discuss the importance of link order.


</Preview>


</Pw>

`add_library()` ALIAS Signature

`add_library()` IMPORTED Signature

`set_target_properties()` Command

Properties on Targets

It's Time To Do CMake Right

More Modern CMake - Deniz Bahadir

Master advanced CMake patterns. This lesson shows you how to use INTERFACE targets to group properties, ALIAS targets for clean namespacing, and IMPORTED targets to integrate pre-compiled third-party libraries into your dependency graph.

Advanced CMake: Using INTERFACE, ALIAS, and IMPORTED Targets

Grouping Usage Requirements with `INTERFACE` Libraries

Practical Example: Enforcing Strict Warnings

The `INTERFACE` Keyword in `target_compile_options()`

The `PRIVATE` Keyword in `target_link_libraries()`

Creating Namespaced Aliases with `ALIAS` Libraries

Using Pre-Compiled Binaries with `IMPORTED` Libraries

Step 1: Changing to an `IMPORTED STATIC GLOBAL` Library

Step 2: Changing the Include Directories to `INTERFACE`

Step 3: Setting the `IMPORTED_LOCATION` Property

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

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

Managing C++ Projects Using CMake

Using INTERFACE, ALIAS, and IMPORTED Libraries

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

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