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

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

Building C++ Programs

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

The Compilation Pipeline

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

Object Files and the Linking Process

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

Static and Shared Libraries

The C++ Build Process

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

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

Organizing a C++ Project

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

Managing Libraries and Dependencies

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

Automated Build Systems and Their Limitations

Project Structure and Dependency Management

Setting up CMake and creating your first project

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

Why CMake?

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

Setting Up a CMake Environment

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

Writing a CMakeLists File

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

Building and Running CMake Projects

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

CMake Project Structure and Subdirectories

Introducing CMake

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

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

CMake Variables and Logging

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

The CMake Cache

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

CMake Commands, Arguments, and Lists

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

CMake Conditionals and Loops

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

Working with the File System

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

Modularizing CMake Code

CMake Language and Fundamentals

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

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

Target Properties

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

Relationships Between Targets

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

Indirect Relationships and the Dependency Graph

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

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

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

Using Shared Libraries

Targets and Dependencies

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

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

Build Configurations (Debug, Release, etc.)

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

Cross-Platform Configurations

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

Handling Different Architectures

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

Cross-Compilation and Toolchain Files

Platforms and Build Configurations

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

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

Finding Dependencies using `find_package()`

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

Creating a Consumable Package

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

Using Installed Packages

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

Fetching External Dependencies

Creating and Consuming Packages

Integrating the vcpkg and Conan package managers to handle external dependencies

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

Integrating CMake and vcpkg

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

vcpkg Commands and Versioning

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

Cross-Compiling with vcpkg

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

Using Conan with CMake

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

Cross-Compilation with Conan

Package Managers

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

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

CMake Presets

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

User Presets and Inheritance

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

Environment Variables and Conditional Presets

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

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

Generator Expressions and Conditional Logic

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

Integrating Tools with `add_custom_command()`

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

Generating Files with Protobuf and `add_custom_command()`

Custom Commands

An introduction to automating common workflow chores by creating custom targets

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

Custom Targets and Build Utilities

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

Using Clang-Format

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

Using File Sets

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

Generating Documentation with Doxygen

Custom Targets

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

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

Automated Testing and CTest

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

Integrating GoogleTest with CMake

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

Assertions and Parameterized Tests

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

Dependency Injection and Mocking

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

Testing Executables

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

Managing a Test Suite

Automated Testing

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

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

Using AddressSanitizer (ASan)

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

Using Google Benchmark

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

Using Clang-Tidy

Automated Analysis

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

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

Source Control with Git

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

Build Servers and Continuous Integration

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

Packaging with CPack

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

Packaging with GitHub Actions

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

Creating Installers with CPack and GitHub Actions

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

Deployment with GitHub Releases

Continuous Integration and Packaging

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

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

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

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

The Full Build Pipeline

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

Complete CMake Language Mastery

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

Advanced Target Management

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

In-Depth Dependency Management

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

Total Workflow Automation

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

End-to-End CI/CD and Deployment

What You'll Learn

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

Intro to C++ Programming

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

New to Programming?

Managing C++ Projects Using CMake

So far, every time we've built our project, we've created the same kind of output. But in real-world projects, we rarely build our code just one way. We need different "flavors" of your build for different purposes.


How many flavors and what they are used for varies from product to product, and the processes the team uses to create that product.  However, almost all projects use at least a `Debug` and `Release` variation:

- A `Debug` build, compiled with no optimizations and full debugging symbols, so you can step through it with a debugger to find bugs.
- A `Release` build, compiled with maximum optimizations and no debug info, making it fast and small for shipping to users.

These different sets of build settings are called **build configurations** or **build types**.


This lesson will teach you how CMake handles this task. We'll discover that there are two fundamentally different kinds of build systems, learn how to control the build type, and learn the modern, portable way to apply configuration-specific settings.


## Specifying the Generator with `-G`


CMake can generate a wide range of project types as part of the configure step.  The generator being used is available as the `CMAKE_GENERATOR` variable:


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


```c++
#<cmake>
cmake_minimum_required(VERSION 3.16)
message(STATUS "Using ${CMAKE_GENERATOR}")#<h>

project(Greeter VERSION "1.0")

add_subdirectory(greeter)
add_subdirectory(app)
```


</CodeFile>


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


```c++
//<o>
-- Using Ninja
```


To see a list of all generators available on your system, you can run `cmake --help`. The output will include a section listing the generators that are available in your environment:


```c++
//<ti>
cmake --help
```


If we want to use a different generator, deleting everything in the existing `/build` directory first is recommended.


Then, to tell CMake which generator to use, we provide its **exact** name as listed in the `--help` command using the `-G` option.


For example, if we wanted to create a Visual Studio 2022 solution, and that was listed as an option in our `cmake --help` output, we would use the following command:


```c++
//<ti>
cmake .. -G "Visual Studio 17 2022"
```


In our build directory, we should now see a `Greeter.sln` file which we can open in Visual Studio.  This file, in conjunction with the `.vcxproj` files, includes all the configuration options we specified in our `CMakeLists.txt` files, but in a format that is natively understood by Visual Studio.


## Single-Config vs. Multi-Config Generators


The most important concept to understand is that CMake generates two different kinds of build systems. The way you handle configurations depends entirely on which type you're using.


### Single-Configuration Generators


Tools like **Unix Makefiles** and **Ninja** are single-configuration generators. This means the entire build directory is dedicated to building just _**one**_ configuration at a time.


A common way of supporting multiple configurations in this context is by having a different directory dedicated to each configuration.


These directories might have names like `build-debug` and `build-release`, or `debug` and `release` subfolders of our main `/build` directory.  For example:


```javascript
//<nh>
(project root)/
└─ build/
  ├─ debug/
  └─ release/
└─ ... (other directories)
```


We then choose the build type (e.g., `Debug` or `Release`) when we run the **configure** step.  We first ensure we're running the command in the correct directory.  For example, to create a `Debug` build, we'd navigate to the `/build/debug` directory.


Then, to specify our build type, we set the `CMAKE_BUILD_TYPE` cache variable using the `-D` option, for example, `-DCMAKE_BUILD_TYPE=Debug`


In our case, we'll also switch from using `..` to `../..`.  This is because we now need to navigate up two levels (eg from `/build/debug` to the project root) to locate our `CMakeLists.txt` file, where we previously only needed to navigate up one level (from `/build`)


```c++
//<ti>
cmake ../.. -DCMAKE_BUILD_TYPE=Debug
```


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


### The `-B` and `-S` Options


If we want to run the `cmake` command from a different directory, we can specify where the build output should be using the `-B` option.


For example, if we were in the `/build` directory, and wanted our output to go into the `/build/debug` directory, our command would look like this:


```c++
//<ti>
cmake .. -B debug/ -DCMAKE_BUILD_TYPE=Debug
```


If we want to be explicit about what the `..` represents (the location of our `CMakeLists.txt` file) we can use the `-S` option:


```c++
//<ti>
cmake -S .. -B debug/ -DCMAKE_BUILD_TYPE=Debug
```


Our `/build/debug` directory is now dedicated to the `Debug` version of our software and, within that directory, we can build that version in the usual way:


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


The key point to remember is that, with single-config generators, the decision of what build type we create is made at **configure** time. The generated files support only that build type.  


However, we can run the configure step multiple times, in different directories and with different `CMAKE_BUILD_TYPE` settings, thereby creating projects with different build types.


### Multi-Configuration Generators


IDEs like **Visual Studio** and **Xcode**, as well as the **Ninja Multi-Config** generator, work differently. They are designed to handle multiple configurations within a single generated project.


The generated Visual Studio Solution (`.sln`) file, for example, contains all the rules needed to build `Debug`, `Release`, and any other configurations.  This is why, if you open that `.sln` file in Visual Studio, there will be a dropdown menu to let you switch between configurations on the fly:


<Img file="vs-build-type-dropdown.png" alt="Screenshow showing Visual Studio's build type dropdown" width="711" height="343" blurHash="L47^}X~q9G4nM|M{-;oztPIUIUt7" />


With these multi-configuration generators, you do _**not**_ set `CMAKE_BUILD_TYPE` at configure time. Instead, you choose the configuration at **build time**.  This means we build our project in much the same way we've done in the past.  The only difference is that, at the build step, we set the `--config` option:


```javascript
//<ti>
cmake ..
```


```javascript
//<ti>
cmake --build . --config Debug
```


This distinction is the source of much confusion for CMake beginners. If we check the `CMAKE_BUILD_TYPE` in our `CMakeLists.txt` or use it to drive logic within an `if()` command, that will work for Makefiles but will fail for Visual Studio, because `CMAKE_BUILD_TYPE` is not set at configure time for multi-config generators.


We'll learn how to write this configuration logic later in the lesson.


### The `CMAKE_CONFIGURATION_TYPES` Variable


The `CMAKE_CONFIGURATION_TYPES` variable stores the list of build types that our multi-config generator supports.  If we're not using a multi-config generator, this variable will not be set:


```c++
#<cmake>
if(CMAKE_CONFIGURATION_TYPES)
  message(STATUS "Generator is multi-config: ${CMAKE_GENERATOR}")
  message(STATUS "Available configs: ${CMAKE_CONFIGURATION_TYPES}")
else()
  message(STATUS "Generator is single-config: ${CMAKE_GENERATOR}")
  message(STATUS "Current build type: ${CMAKE_BUILD_TYPE}")
endif()
```


```c++
//<o>
-- Generator is multi-config: Visual Studio 17 2022
-- Available configurations: Debug;Release;RelWithDebInfo;MinSizeRel
```


<Pw>


## Standard Build Types


CMake comes with four standard, built-in build types. For each one, it knows a default set of compiler flags.

1. `Debug`: For debugging. Enables debug symbols and disables optimizations..
2. `Release`: For distribution. Enables optimizations and disables debug symbols.
3. `RelWithDebInfo`: Release with Debug Info. A hybrid that enables optimizations but also generates debug symbols. Good for profiling or debugging optimized code.
4. `MinSizeRel`: Minimum Size Release. Optimizes for the smallest binary size instead of speed.

We can check what compiler flags are associated with a configuration by examining the `CMAKE_CXX_FLAGS_<CONFIG>` variables.  For example:


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


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

message("Debug: ${CMAKE_CXX_FLAGS_DEBUG}") #<h>
message("Release: ${CMAKE_CXX_FLAGS_RELEASE}") #<h>
message("RelWithDebInfo: ${CMAKE_CXX_FLAGS_RELWITHDEBINFO}") #<h>
message("MinSizeRel: ${CMAKE_CXX_FLAGS_MINSIZEREL}") #<h>

add_subdirectory(greeter)
add_subdirectory(app)
```


</CodeFile>


```c++
//<o>
Debug: -g
Release: -O3 -DNDEBUG
RelWithDebInfo: -O2 -g -DNDEBUG
MinSizeRel: -Os -DNDEBUG
```


## Generator Expressions


We've seen that the `CMAKE_BUILD_TYPE` is only available at configure time if we're using a single-config generator, but we want our `CMakeLists.txt` file to be portable.  It should support both single and multi-config generators,


To this end, we typically avoid using the `CMAKE_BUILD_TYPE` expression in our configuration logic.  We instead use **generator expressions**.


A generator expression is a special piece of syntax, written as `$<...>`, that is _**not evaluated at configure time**_. Instead, it's written into the native build files and evaluated at **build time**. This allows the expression to react to the configuration chosen by the user in their IDE or with the `--config` flag.


The most common generator expression is `$<CONFIG:...>`.  Let's see a common example of using such an expression, and then explain what's going on.


Imagine we we want to define a preprocessor macro `ENABLE_LOGGING` only in `Debug` builds of our `GreeterApp`.  Rather than being tempted to check the `CMAKE_BUILD_TYPE` in an `if()` statement, we should instead use a generator expression:


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

target_compile_definitions(GreeterApp PRIVATE
  $<$<CONFIG:Debug>:ENABLE_LOGGING>#<h>
)
```


</CodeFile>


Let's break this down:

- `$<CONFIG:Debug>`: This part of the expression evaluates to `1` if the active configuration is `Debug`, and `0` otherwise.
- `$<1:...>` evaluates to whatever content comes after the `:`, which is `ENABLE_LOGGING` in this example. `$<0:...>` evaluates to an empty string.
- So, if we build in `Debug`, the whole expression becomes `ENABLE_LOGGING`, and the `target_compile_definitions()` command adds `DENABLE_LOGGING` to the compiler flags.
- If we build using any other type, the expression becomes an empty string, and the command does nothing.

This logic is evaluated by the native build system, so it works perfectly whether `Debug` was chosen at configure time (eg Makefiles) or build time (eg Visual Studio).


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


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

int main() {
#ifdef ENABLE_LOGGING#<h>
  std::cout << "I'll be logging extra stuff in this build\n";#<h>
#endif#<h>
  std::cout << get_greeting();
  return 0;
}
```


</CodeFile>


```c++
//<ti>
cmake .. -DCMAKE_BUILD_TYPE=Debug
```


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


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


```c++
//<o>
I'll be logging extra stuff in this build
Hello from the modular greeter library!
```


### More Examples


Other common uses for generator expressions include conditionally adding files to a build:


```c++
#<cmake>
# Add a file only in Debug configurations
target_sources(GreeterApp PRIVATE
  src/main.cpp
  $<$<CONFIG:Debug>:src/debug_helpers.cpp>#<h>
)
```


We can also use them for conditionally linking to different versions of a library. Many precompiled third-party libraries provide a debug version (e.g., `liblogger_d.a`) and a release version (`liblogger.a`).


You can handle this cleanly with generator expressions:


```c++
#<cmake>
target_link_libraries(GreeterApp PRIVATE
  # Link to the debug version of a library in Debug builds
  $<$<CONFIG:Debug>:logger_d>
  # Link to the optimized version in Release builds
  $<$<CONFIG:Release>:logger>
)
```


This tells CMake: "When building in Debug mode, link to `logger_d`. When building in Release mode, link to `logger`."


## Custom Build Types and Customizing Flags


While the four standard types are usually enough, you can define your own. For example, you might want a `Profile` build with specific instrumentation flags.


We'll learn the best way to define a completely new build type later in the course, but for now, let's see how we can _**modify**_ the flags of an existing build type. For instance, let's imagine we wanted to treat warnings as errors in our `Debug` build.


To do this, we'd use the `add_compile_options()` command with a generator expression.  To treat warnings as errors, you'd set `-Werror` if you're using Clang/GCC, or `/WX` for MSVC.  We've written this for Clang/GCC in this example, but we'll learn how to make it more portable in the next lesson:


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


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

add_compile_options(#<h>
  $<$<CONFIG:Debug>:-Werror>#<h>
)#<h>

add_subdirectory(greeter)
add_subdirectory(app)
```


</CodeFile>


### Customizing for a Single Target


Note that the `add_compile_options()` command in this example is different from the `target_compile_options()` we used previously.  The `add_compile_options()` applies the options to **all** targets in this `CMakeLists.txt` file, including any that are added through `add_subdirectory()`.


If we wanted to apply the options to only one target, we'd use `target_compile_options()`.  We provide our target's name as the first argument, and the propagation behavior (`PRIVATE`, `INTERFACE`, or `PUBLIC`) as the second:


```c++
#<cmake>
target_compile_options(SomeTarget PRIVATE
  $<$<CONFIG:Debug>:-Werror>
)
```


With either approach, configuring or building in `Debug` mode and introducing a warning in our code will cause compilation to fail as intended:


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


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

[[deprecated("Don't use this")]]//<h>
void NastyFunction() {};//<h>

int main() {
  NastyFunction();//<w>
  std::cout << get_greeting();
  return 0;
}
```


</CodeFile>


```c++
//<ti>
cmake -DCMAKE_BUILD_TYPE=Debug ..
```


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


```c++
//<oe>
error: 'void NastyFunction()' is deprecated: Don't use this [-Werror=deprecated-declarations]
    8 |   NastyFunction();
      |   ~~~~~~~~~~~~~^~
cc1plus.exe: all warnings being treated as errors
ninja: build stopped: subcommand failed.
```


## Summary


Build configurations are an important part of any C++ project, and CMake provides a portable framework for managing them.

- **Standard Build Types**: CMake knows about `Debug`, `Release`, `RelWithDebInfo`, and `MinSizeRel`, and provides default flags for each.
- **Two Generator Types**: _Single-configuration_ (Makefiles, Ninja) set the build type at configure time (`-DCMAKE_BUILD_TYPE=Debug`). _Multi-configuration_ (Visual Studio, Xcode) set it at build time (`-config Debug`).
- **Generator Expressions**: Use `$<...>` expressions, especially `$<CONFIG:...>`, to write configuration-specific logic that works portably across all generator types.
- **Customize Flags**: To modify the default flags for a build type, use the `add_compile_options()` or `target_compile_options()` commands in conjunction with a generator expression.

</Pw>

Static and Shared Libraries - Concepts and Usage

`CMAKE_BUILD_TYPE`

CMake Generator Expressions

Understand build configurations

what is the difference between configuration type and build type in cmake

CMake and the Default Build Type

Oh No! More Modern CMake - Deniz Bahadir

Build Systems and Their Limitations

Master CMake build configurations. This lesson explains the difference between single-config (Makefiles) and multi-config (Visual Studio) generators, how to use CMAKE_BUILD_TYPE, and how to write portable, configuration-specific settings with generator expressions.

CMake Build Configurations: Debug, Release, and Generator Expressions

Single-Config vs. Multi-Config Generators

Build Configurations (Debug, Release, etc.)

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

Managing C++ Projects Using CMake