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

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

Building C++ Programs

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

The Compilation Pipeline

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

Object Files and the Linking Process

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

Static and Shared Libraries

The C++ Build Process

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

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

Organizing a C++ Project

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

Managing Libraries and Dependencies

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

Automated Build Systems and Their Limitations

Project Structure and Dependency Management

Setting up CMake and creating your first project

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

Why CMake?

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

Setting Up a CMake Environment

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

Writing a CMakeLists File

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

Building and Running CMake Projects

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

CMake Project Structure and Subdirectories

Introducing CMake

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

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

CMake Variables and Logging

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

The CMake Cache

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

CMake Commands, Arguments, and Lists

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

CMake Conditionals and Loops

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

Working with the File System

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

Modularizing CMake Code

CMake Language and Fundamentals

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

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

Target Properties

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

Relationships Between Targets

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

Indirect Relationships and the Dependency Graph

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

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

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

Using Shared Libraries

Targets and Dependencies

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

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

Build Configurations (Debug, Release, etc.)

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

Cross-Platform Configurations

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

Handling Different Architectures

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

Cross-Compilation and Toolchain Files

Platforms and Build Configurations

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

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

Finding Dependencies using `find_package()`

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

Creating a Consumable Package

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

Using Installed Packages

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

Fetching External Dependencies

Creating and Consuming Packages

Integrating the vcpkg and Conan package managers to handle external dependencies

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

Integrating CMake and vcpkg

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

vcpkg Commands and Versioning

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

Cross-Compiling with vcpkg

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

Using Conan with CMake

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

Cross-Compilation with Conan

Package Managers

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

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

CMake Presets

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

User Presets and Inheritance

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

Environment Variables and Conditional Presets

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

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

Generator Expressions and Conditional Logic

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

Integrating Tools with `add_custom_command()`

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

Generating Files with Protobuf and `add_custom_command()`

Custom Commands

An introduction to automating common workflow chores by creating custom targets

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

Custom Targets and Build Utilities

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

Using Clang-Format

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

Using File Sets

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

Generating Documentation with Doxygen

Custom Targets

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

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

Automated Testing and CTest

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

Integrating GoogleTest with CMake

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

Assertions and Parameterized Tests

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

Dependency Injection and Mocking

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

Testing Executables

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

Managing a Test Suite

Automated Testing

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

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

Using AddressSanitizer (ASan)

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

Using Google Benchmark

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

Using Clang-Tidy

Automated Analysis

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

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

Source Control with Git

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

Build Servers and Continuous Integration

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

Packaging with CPack

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

Packaging with GitHub Actions

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

Creating Installers with CPack and GitHub Actions

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

Deployment with GitHub Releases

Continuous Integration and Packaging

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

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

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

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

The Full Build Pipeline

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

Complete CMake Language Mastery

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

Advanced Target Management

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

In-Depth Dependency Management

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

Total Workflow Automation

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

End-to-End CI/CD and Deployment

What You'll Learn

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

Intro to C++ Programming

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

New to Programming?

Managing C++ Projects Using CMake

We've designed a modular build system using `INTERFACE`, `ALIAS`, and `IMPORTED` targets. We have a clear dependency graph, and properties flow automatically from producers to consumers.


But so far, we've only been building static libraries. In this lesson, we'll build our first shared library.


## User-Configurable Library Types


Right now, our `greeter/CMakeLists.txt` defines our library like this:


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


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

# add_library called without specifying the type
add_library(GreeterLib src/Greeter.cpp)#<h>

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


</CodeFile>


As we learned, when the type is omitted, `add_library()` defaults to creating a `STATIC` library. But what if we wanted to use a shared library instead?  The most direct solution would be to simply add the `SHARED` keyword to our `add_library()` command:


```c++
#<cmake>
add_library(GreeterLib SHARED src/Greeter.cpp)
```


Alternatively, we can leave our library type unspecified, and instead allow users to specify whether they want static or shared libraries by setting the `BUILD_SHARED_LIBS` cache variable.


### How `BUILD_SHARED_LIBS` Works


`BUILD_SHARED_LIBS` is a special variable recognized by CMake. When an `add_library()` command is called without an explicit `STATIC`, `SHARED`, or `INTERFACE` keyword, it checks the value of `BUILD_SHARED_LIBS`:

- If `BUILD_SHARED_LIBS` is `ON`, it creates a `SHARED` library.
- If `BUILD_SHARED_LIBS` is `OFF` (or not defined), it creates a `STATIC` library.

To expose this to the user, the convention is to add a friendly `option()` to your root `CMakeLists.txt`.


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


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

# Provide a user-facing option to control the library type
option(BUILD_SHARED_LIBS "Build libraries as shared" OFF) #<h>

project(Greeter VERSION "1.0")

add_subdirectory(greeter)
add_subdirectory(app)
```


</CodeFile>


We haven't changed the `greeter/CMakeLists.txt` file at all. The `add_library(GreeterLib ...)` call will now automatically respect this global setting. This small change means consumers can now control the library type directly from the command line without ever touching our build scripts.


<Pw>


## Exporting and Importing Symbols


On some environments, most notably Windows, we need to do some extra work when we want to use shared libraries.

- When we want a symbol to be visible to consumers of a shared library, we need to explicitly **export** it
- When a symbol we're using is defined in a shared library, we need to explicitly **import** it

With MSVC, for example, we export a symbol by annotating it with `__declspec(dllexport)`.  This means that, in our library code, we'd want something like this:


```c++
// This symbol should be visible to consumers
__declspec(dllexport) void some_function() {//<h>
  // ...
}
```


And, when code elsewhere wants to use a symbol defined in that library, it would annotate the declaration with `__declspec(dllimport)`.  This means that, in our executable target, our declaration of that symbol might look something like this:


```c++
// This symbol will come from a shared library
__declspec(dllimport) void some_function();//<h>

int main() {
  some_function();
  return 0;
}
```


This can be annoying so, to make things easier, we tend to implement this annotation logic in a single place - our library's header file.  The code in this header file naturally gets added to every translation unit it is needed via `#include` directives.


The symbols in the translation unit used to compile the library will need `dllexport` attributes, whilst the translation unit of any library consumer will need `dllimport` attributes.  We can use the preprocessor to switch between them.  For example:


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


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

#ifdef _WIN32
  #ifdef GREETER_EXPORTS
    #define GREETER_API __declspec(dllexport)//<h>
  #else
    #define GREETER_API __declspec(dllimport)//<h>
  #endif
#else
  #define GREETER_API//<h>
#endif

// Any symbol that is part of our public API
// can now use the `GREETER_API` macro:
GREETER_API std::string get_greeting();//<h>

// More examples
GREETER_API void another_function();//<h>
GREETER_API bool yet_another(int x);//<h>
extern GREETER_API bool some_variable;//<h>

// Not exported
void some_internal_function();//<h>
```


</CodeFile>


This header file now annotates `get_greeting()` based on `GREETER_API`, which has one of three possible values:

- If we are targeting Windows and `GREETER_EXPORTS` is defined, `GREETER_API` will be replaced with `__declspec(dllexport)`, thereby flagging our symbol for export.
- If we are targeting Windows and `GREETER_EXPORTS` is **not** defined, our symbol is flagged as being imported, as `GREETER_API` will be replaced with `__declspec(dllimport)`.
- If we're not compiling for Windows, `GREETER_API` will have no value, meaning the preprocessor will remove it and our forward declaration will simply be `std::string get_greeting()`.

Now, to make everything work, we just need to define `GREETER_EXPORTS`, but only for our library target:


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


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

add_library(GreeterLib src/Greeter.cpp)

target_compile_definitions(GreeterLib PRIVATE GREETER_EXPORTS)#<h>

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


</CodeFile>


This means that, if we're targetting Windows, the `Greeter.h` contents in our library's translation unit will have `GREETER_API` set to `__declspec(dllexport)`, whilst our executable's translation unit will use `__declspec(dllimport)`.


## Using `GenerateExportHeader`


To help with managing the visibility of symbols in shared libraries, CMake comes bundled with a useful module called `GenerateExportHeader`, which provides a  `generate_export_headers()` command.


This command automatically creates a header file containing the preprocessor logic we just walked through.  Below, we use it to generate a `greeter_export.h` file containing our `GREETER_API` macro.


This header file will be placed in our library's build directory, so we'll also add `CMAKE_CURRENT_BINARY_DIR` to our search paths to ensure it can be found:


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


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

add_library(GreeterLib src/Greeter.cpp)

include(GenerateExportHeader)#<h>

generate_export_header(GreeterLib#<h>
  EXPORT_MACRO_NAME GREETER_API#<h>
  EXPORT_FILE_NAME greeter_export.h#<h>
)#<h>

target_include_directories(GreeterLib PUBLIC
  "${CMAKE_CURRENT_SOURCE_DIR}/include"
  
  # For greeter_export.h (generated) #<h>
  "${CMAKE_CURRENT_BINARY_DIR}" #<h>
)

# No longer needed - generate_export_header() sets the
# required definition on the target we provided as its
# first argument
target_compile_definitions(GreeterLib PRIVATE GREETER_EXPORTS)#<d>
```


</CodeFile>


We can now `#include` this generated header file to replace our previous logic: 


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


```c++
#pragma once
#include <string>
#include "greeter_export.h"//<h>

#ifdef _WIN32//<d>
  #ifdef GREETER_EXPORTS//<d>
    #define GREETER_API __declspec(dllexport)//<d>
  #else//<d>
    #define GREETER_API __declspec(dllimport)//<d>
  #endif//<d>
#else//<d>
  #define GREETER_API//<d>
#endif//<d>

GREETER_API std::string get_greeting();
```


</CodeFile>


This `generate_export_header()` approach is more robust than our basic manual implementation, as it contains logic to handle import/export requirements beyond just Windows.


It also defines further macros that we can optionally use if we want to explicitly declare some symbols as being internal (that is, **not** exported), or to flag some symbols as deprecated.


Official documentation for the `GenerateExportHeader` module is available [here](https://cmake.org/cmake/help/latest/module/GenerateExportHeader.html).


## Building a Shared Library


Let's walk through the entire process to see the effect of this change.


### Configure with `BUILD_SHARED_LIBS` ON


From our `build` directory, we'll re-configure the project, this time setting our new option to `ON`:


```c++
//<ti>
cmake -DBUILD_SHARED_LIBS=ON ..
```


### Build the Project


Now, we run the build command as usual.


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


If you inspect your `build/greeter` directory, you'll see that instead of a static library (`.a` or `.lib`), CMake has produced a shared library (`.so` on Linux, `.dll` on Windows).


### The Runtime Linking Problem


Now, let's try to run our `GreeterApp` (or `GreeterApp.exe`) application from the `build/app` directory:


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


As you may have guessed, our `GreeterApp` now depends on a shared library that it probably can't find.  As such, our program will likely error, or just appear to do nothing at all.


```c++
//<oe>
./app/GreeterApp: error while loading shared libraries: libGreeterLib.so: cannot open shared object file: No such file or directory
```


The operating system's loader saw that `GreeterApp` needs `libGreeterLib.so`, but it didn't know where to find it.


The loader only checks a few specific places for any shared library that our executable needs. The `/build/greeter` directory where our shared library is placed after compilation is not one of them.


This is a classic deployment problem. Our build directory is a messy, intermediate workspace. It's not a clean, reliable environment for running our application. To solve this, we need a proper installation step.


## Preparing for Distribution with `install()`


The `install()` command is CMake's mechanism for taking the outputs from a messy build directory and arranging them into a clean, distributable layout. This "install" directory is what you would package into a `.zip` file or an installer to give to other people.


Installation, packaging and distribution is an important topic that we'll cover in a dedicated chapter later in the course.  But for now, let's walk through a quick example, as the installation process sets some useful context of how CMake can also prepare our project for distribution to users. 


The `install()` command tells CMake what to do when we run the `--install` build step.  We'll cover how to run that soon, but lets first set up what should happen when we do.


### Installing the Executable


In `app/CMakeLists.txt`, we'll add an install rule for our executable:


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


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

add_executable(GreeterApp src/main.cpp)
target_link_libraries(GreeterApp GreeterLib)

# Install the final executable to a 'bin' directory
install(TARGETS GreeterApp DESTINATION "${CMAKE_SOURCE_DIR}/bin") #<h>
```


</CodeFile>


Our arguments are the following:

1. The `TARGETS` keyword, informing CMake that the installation rule we are setting applies to targets, and that the next argument(s) will specify those targets.
2. The targets that these rules apply to.  We're applying this rule only to the `GreeterApp` target, so only a single argument follows `TARGETS` in this case. We could add more if needed.
3. The `DESTINATION` keyword informs CMake that the next argument will specify where we want our files installed to.
4. The `"${CMAKE_SOURCE_DIR}/bin"` argument will cause our files to be installed in a directory called `bin` (binary), which is a common convention.  The use of the `CMAKE_SOURCE_DIR` prefix specifies that this `bin` directory will always be in the root of our project.

Eventually, users should be able to specifiy where on their system the program should be installed, but we'll keep things simple for now.  We'll learn much more about installation later in the course.


### Installing the Library


Let's set the same `install()` rules for our library:


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


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

add_library(GreeterLib src/Greeter.cpp)

include(GenerateExportHeader)#<h>

generate_export_header(GreeterLib#<h>
  EXPORT_MACRO_NAME GREETER_API#<h>
  EXPORT_FILE_NAME greeter_export.h#<h>
)#<h>

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

install(TARGETS GreeterLib #<h>
  DESTINATION "${CMAKE_SOURCE_DIR}/bin"#<h>
)#<h>
```


</CodeFile>


Combined, these rules will place our executable file and shared library in the same location - within `/bin` in our project root.


### Setting the Runtime Library Search Path (`rpath`)


Placing our shared library in the same location as our executable is enough to let Windows find it.  When an `.exe` file asks for a `.dll` file, Windows will automatically search the same directory.


However, on Unix-like systems (including macOS and Linux), we need one more step.  We'll set the `INSTALL_RPATH` property on our `GreeterApp` target.  This property gets embedded into the executable, and gives Unix-like systems some additional hints about where that executable's dependencies might be.


The special `"$ORIGIN"` path will be resolved to the directory the executable is in.  This means the platform will look in that same location for any libraries we need, replicating Windows' behavior:


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


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

add_executable(GreeterApp src/main.cpp)
target_link_libraries(GreeterApp GreeterLib)

install(TARGETS GreeterApp DESTINATION "${CMAKE_SOURCE_DIR}/bin")

set_target_properties(GreeterApp PROPERTIES #<h>
  INSTALL_RPATH "$ORIGIN" #<h>
) #<h>
```


</CodeFile>


## The End-to-End Installation Workflow


Now let's see our new installation rules in action.


### Configuring and Building


First, we configure and build our project as usual. Let's build the shared library version again.


```c++
//<ti>
cmake -DBUILD_SHARED_LIBS=ON ..
```


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


Now that our build is ready, there are two options for installing it.  The first option is likely to work in most cases but, if you're using a "multi-config" generator (such as Visual Studio), you may need to use the second option.


### Option 1: Installation using the Default Configuration


Now, we execute the `--install` step. As with the previous step, we'll run this from our `./build` directory, and use the `.` command to tell CMake the output of our build is in this same directory:


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


This command runs the `install()` rules we defined. It finds the built artifacts in the current directory and its subdirectories, and copies them to the locations we requested in our `DESTINATION` arguments.


### Option 2: Installation with Multi-Config Generators


Some generators, such as Visual Studio, can output different "configurations" of our targets from the same `/build` directory.  Examples include the "Debug" and "Release" configurations that you may be familiar with, but don't worry if you're not - we introduce them in the next chapter.


When using `cmake --install`, you may need to specify **which** configuration you want to install.  You can generally tell which configuration your build step created by examining the output from the `--build` command but, in most cases, it tends to be a "Debug" configuration by default.


You can pass the `--config` argument as part of the `cmake --install` instruction to specify that this is the output you want to install:


```c++
//<ti>
cmake --install . --config Debug
```


We cover build types and multi-config generators in detail in the next chapter.


### Inspecting the Result


If you now look in the `bin` directory, you should see both our library and our executable.  And, if we run the executable from that location, everything should work.


The following command assumes we're currently in the build directory, so `..` navigates up to our project root, and `/bin` navigates to the bin directory in that location.  Remember to add `.exe` on Windows:


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


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


This was only a brief introduction to a very large topic, and our basic implementation isn't flexible or robust.  For example:

- Users cannot control the installation directory.  We've hardcoded the destination to the `/bin` directory in the project root.  The `cmake --install` command even has a `--prefix` option to let users set their location, and this flexibility is required to package and ship our project, but our `CMakeLists.txt` files doesn't support it.
- If we revert back to a static library (such as by setting `-DBUILD_SHARED_LIBS=OFF`) then the library will still be copied over to our `/bin` directory, even though it's no longer needed.
- Installation isn't just for end-users wanting to run our executable.  It is also how we would prepare our libraries to be used by other developers.  The implementation for that use case looks totally different to what we set up here.

We'll revisit installation and packaging later in the course, addressing all these limitations and much more.


## Summary


This lesson covered some of the most important practical aspects of authoring and using libraries in a modern CMake project.

- **Configurable Library Types**: Use the `BUILD_SHARED_LIBS` option to allow users to easily switch between `STATIC` and `SHARED` builds of your libraries.
- **Installation for Distribution**: Use the `install()` command to gather your project's artifacts into a clean, distributable directory structure.  This separates it from the temporary build tree and prepares it for packaging and shipping (which we'll cover later).

<Preview>


### Build Configurations


We've made our libraries configurable between `STATIC` and `SHARED`, but what about the most common configuration of all: `Debug` vs. `Release`? How do we apply different compiler flags for optimization and debugging?


In the next chapter, we will explore these build configurations. We'll learn how CMake manages them, how this differs between single-configuration generators (like Makefiles) and multi-configuration generators (like Visual Studio), and how to use **generator expressions** to apply settings conditionally for a specific build type.


</Preview>


</Pw>

Added note on multi-config generators, and fixed spelling error

Property Groups, Aliases, and Imports

`BUILD_SHARED_LIBS` Variable

`install()` Command

CMake Tutorial - Packaging an Installer

A guide to advanced CMake topics. Learn to use BUILD_SHARED_LIBS for configurable library types and the install() commands for creating reusable packages.

CMake - Building and Installing Shared Libraries

Preparing for Distribution with `install()`

Setting the Runtime Library Search Path (`rpath`)

Option 1: Installation using the Default Configuration

Option 2: Installation with Multi-Config Generators

Using Shared Libraries

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

Managing C++ Projects Using CMake