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 <InlineLessonPromo url="cmake/cross-platform-cmake" title="Cross-Platform Configurations" description="Learn the tools and patterns needed to write portable CMakeLists.txt files that work seamlessly across platforms and compilers">previous lesson</InlineLessonPromo>, we learned how to write portable `CMakeLists.txt` files that can adapt to different operating systems and compilers. By detecting variables like `WIN32` and `MSVC`, we can conditionally include the right source files and set the right flags, creating a single build script that works everywhere.


But the platform is more than just the OS. The underlying hardware **architecture** also plays a role. A program compiled for a 64-bit Intel processor won't run on a 32-bit ARM chip. While these differences are often handled by the compiler, sometimes our build system needs to be aware of them.


This lesson focuses on handling architectural differences. We'll cover:

- The classic 32-bit vs. 64-bit distinction and how to detect it.
- The unique challenge on macOS of supporting both Intel and Apple Silicon CPUs by building a **universal binary**.

## Handling Architecture (32-bit vs. 64-bit)


Let's start with a quick overview. The "bitness" of an architecture (32-bit or 64-bit) primarily refers to the size of its memory addresses and CPU registers.

- A **32-bit** architecture can address a maximum of $2^{32}$ bytes of memory, which is 4 GiB. Pointers and fundamental types like `long` are often 32 bits wide.
- A **64-bit** architecture can address a theoretical maximum of $2^{64}$ bytes, which is an astronomical amount. Pointers are 64 bits wide.

Today, 64-bit systems are overwhelmingly dominant in desktop and server computing. However, 32-bit architectures are still relevant in some embedded systems or for maintaining compatibility with older legacy applications.


Your build system might need to know the target architecture to:

- Link against the correct version of a pre-compiled third-party library.
- Enable architecture-specific optimizations or code paths.
- Define preprocessor macros that let your C++ code adapt to the pointer size.

### The `CMAKE_SIZEOF_VOID_P` Variable


The canonical way to check the "bitness" of the target architecture in CMake is by inspecting the `CMAKE_SIZEOF_VOID_P` variable. This variable holds the size, in bytes, of a void pointer (`void*`).

- On a **64-bit** target, `sizeof(void*)` is **8** bytes (64 bits).
- On a **32-bit** target, `sizeof(void*)` is **4** bytes (32 bits).

CMake determines this value by doing a small test compilation when it first identifies the compiler. You can then use this variable in an `if()` block to make decisions.


### Practical Example: Architecture-Specific Macros


A common pattern is to use CMake to detect the architecture and then pass that information down to your C++ code via a preprocessor definition. This keeps the platform detection logic in your build script, allowing your C++ code to focus on the implementation.


Let's modify our `GreeterLib` to report the architecture it was compiled for.


First, we'll update `greeter/CMakeLists.txt` to check `CMAKE_SIZEOF_VOID_P` and define a macro accordingly.


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


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

add_library(GreeterLib src/Greeter.cpp)

if(CMAKE_SIZEOF_VOID_P EQUAL 8) #<h>
  target_compile_definitions(GreeterLib PRIVATE ARCH_64BIT) #<h>
  message(STATUS "Targeting 64-bit architecture.") #<h>
else() #<h>
  target_compile_definitions(GreeterLib PRIVATE ARCH_32BIT) #<h>
  message(STATUS "Targeting 32-bit architecture.") #<h>
endif() #<h>

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


</CodeFile>


```c++
//<o>
-- Targeting 64-bit architecture.
```


We've set the compile definition as `PRIVATE` because this is an internal detail. The C++ code inside `GreeterLib` will use this macro, but consumers of the library don't need to know about it.


Let's test this in `Greeter.cpp`, using the preprocessor macros we just defined to choose the correct string at compile time.


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


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

std::string get_arch_string() { //<h>
#if defined(ARCH_64BIT) //<h>
  return "Compiled for 64-bit!"; //<h>
#elif defined(ARCH_32BIT) //<h>
  return "Compiled for 32-bit!"; //<h>
#else  //<h>
  return "Unknown architecture."; // Fallback //<h>
#endif  //<h>
} //<h>

std::string get_greeting() {
  return "Hello from the modular greeter library! "
    + get_arch_string();//<h>
}
```


</CodeFile>


Now, if we re-configure and build, the `message()` command will tell us what CMake detected, and our application will confirm it.


```c++
//<o>
Hello from the modular greeter library! Compiled for 64-bit!
```


<Pw>


## Creating 32-Bit Builds


What if you're on a 64-bit machine but need to build a 32-bit version of your application, perhaps for legacy compatibility?


The direct way is to pass the appropriate compiler and linker flag. This is `-m32` on GCC/Clang:


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


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

if(MSVC)
  # This is handled by the generator (covered next)
else()
  set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -m32")#<h>
  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -m32")#<h>
  set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -m32")#<h>
endif()

project(Greeter VERSION "1.0")

add_subdirectory(greeter)
add_subdirectory(app)
```


</CodeFile>


This is generally discouraged because it hardcodes compiler-specific flags, and it means our build script only works in environments that natively support 32 bit architectures.


In most real-world projects, this is best handled with a **toolchain file**. A toolchain file is a separate `.cmake` script that tells CMake how to configure the compilers and flags for a specific target platform.


We will cover toolchain files in detail in the <InlineLessonPromo url="cmake/cross-compilation-and-toolchain-files" title="Cross-Compilation and Toolchain Files" description="Learn to build for different operating systems and architectures using CMake's cross-compilation support and toolchain files.">next lesson</InlineLessonPromo>.


### Creating 32-bit Builds with MSVC (Visual Studio)


If you're using a Visual Studio generator, the recommended way of generating a 32-bit build, or any other high-level architecture, is through the `-A` flag when configuring the project.  For example:


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


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


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


## Advanced: Customising Instruction Sets


When intervening in the architecture we're compiling for, we may also need to further customise the instruction set that is used.  This is done using compiler flags, which CMake can set through the `add_compile_options()` or `target_compile_options()` commands.


For example, SSE2 is an instruction set extension for x86 (32-bit) processors that can make some computations faster. The following example enables the SSE2 extension by setting the appropriate flags across MSVC, GCC, and GNU:


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


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

if(MSVC)
  add_compile_options(/arch:SSE2)#<h>
else()
  set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -m32")
  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -m32")
  set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -m32")
  add_compile_options(-msse2)#<h>
endif()

project(Greeter VERSION "1.0")

add_subdirectory(greeter)
add_subdirectory(app)
```


</CodeFile>


Note that we generally **don't** need to intervene in this way.  CMake and our compiler will use sensible defaults, particularly when we're building our software on the same architecture that will be used to run it.


We're demonstrating these customisations as a reference for when we **do** need to explicitly intervene and use non-default configurations.


### Using the `CheckCXXCompilerFlag` Module


The previous example assumes that our compiler supports a specific flag based on it's family.  For example, we're assuming that `-msse2` is supported if the compiler is **not** MSVC.


The `CheckCXXCompilerFlag` module provides a more direct approach to this.  It includes a `check_cxx_compiler_flag()` command that tests if our currently configured compiler supports a specific flag, and sets that result in a variable.


We provide the flag as the first argument, and the variable we want to set as the second.  We can use it like this:


```c++
#<cmake>
include(CheckCXXCompilerFlag)#<h>

# Probe compiler support
check_cxx_compiler_flag("-msse2" HAS_MSSE2)#<h>
check_cxx_compiler_flag("/arch:SSE2" HAS_ARCH_SSE2)#<h>

# Set the supported flag
if (HAS_MSSE2)#<h>
  add_compile_options(-msse2)
elseif (HAS_ARCH_SSE2)#<h>
  add_compile_options(/arch:SSE2)
endif()
```


### Reminder: Per-Target Configuration


If we want to set compiler flags only for a specific target, we can replace `add_compile_options()` with the `target_compile_options()` command we covered in the previous lesson:


```c++
#<cmake>
if (HAS_MSSE2)
  target_compile_options(SomeTarget PRIVATE -msse2)
elseif (HAS_ARCH_SSE2)
  target_compile_options(SomeTarget PRIVATE /arch:SSE2)
endif()
```


Note this must be used **after** the target is created - that is, **after** the `add_executable()` or `add_library()` command.


### Reminder: Interface Libraries


Remember, we can create <InlineLessonPromo url="cmake/cmake-property-groups-aliases-and-imports" title="Using `INTERFACE`, `ALIAS`, and `IMPORTED` Libraries" description="Learn to use abstract target types like `INTERFACE`, `ALIAS`, and `IMPORTED` to model complex project needs, organize build properties, and integrate pre-compiled binaries.">interface libraries</InlineLessonPromo> to encapsulate low level configurations like this.  Doing so is particularly recommended if the same configuration is intended to be reused across multiple targets.


Below, we create a `UseSSE2` interface library that includes our compiler configuration:


```c++
#<cmake>
include(CheckCXXCompilerFlag)

# Create interface target
add_library(UseSSE2 INTERFACE)

# Probe compiler support
check_cxx_compiler_flag("-msse2" HAS_MSSE2)
check_cxx_compiler_flag("/arch:SSE2" HAS_ARCH_SSE2)

# Attach the supported flag
if (HAS_MSSE2)
  target_compile_options(UseSSE2 INTERFACE -msse2)
elseif (HAS_ARCH_SSE2)
  target_compile_options(UseSSE2 INTERFACE /arch:SSE2)
endif()
```


We can then "link" against this library any time a target needs those settings:


```c++
#<cmake>
add_executable(SomeTarget SomeFile.cpp)
target_link_libraries(SomeTarget PRIVATE UseSSE2)
```


## macOS Architectures: Intel and Apple Silicon


The world of Apple computing presents a unique architectural challenge. For many years, Macs used Intel processors with the `x86_64` architecture. In 2020, Apple began transitioning to their own "Apple Silicon" chips (M1, M2, etc.), which use the `arm64` architecture.


During this transition period, developers often need to ship applications that run natively on _**both**_ types of Macs. Apple's solution is the **universal binary**, sometimes also known as a **fat binary**.


A universal binary is a single executable file that contains the compiled machine code for multiple architectures. When you run it, the macOS loader (`dyld`) automatically detects the host CPU and executes the appropriate "slice" of the binary. This provides the best performance on both platforms without requiring separate downloads.


### The `CMAKE_OSX_ARCHITECTURES` Variable


CMake provides a simple way to control this: the `CMAKE_OSX_ARCHITECTURES` variable. This variable is only used on Apple platforms. You can set it to a semicolon-separated list of the architectures you want to include in the final binary.


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


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

if(APPLE) #<h>
  # This tells the compiler to build for both Intel (x86_64) and
  # Apple Silicon (arm64), and the linker to combine them.
  set(CMAKE_OSX_ARCHITECTURES "x86_64;arm64") #<h>
  message(STATUS "Configuring for Universal Binary") #<h>
endif() #<h>

project(Greeter VERSION "1.0")

add_subdirectory(greeter)
add_subdirectory(app)
```


</CodeFile>


That's it! When you configure and build this project on a Mac, CMake will automatically pass the correct flags to the compiler and linker (e.g., `-arch x86_64 -arch arm64`) to produce a universal binary.


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


```c++
//<o>
-- Configuring for Universal Binary
```


After building, we can examine the content of our executable and confirm it is a univeral binary by passing its path to the `file` command:


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


The output should be something like:


```c++
//<o>
Mach-O universal binary with 2 architectures:
 for architecture x86_64: Mach-O 64-bit executable x86_64
 for architecture arm64:  Mach-O 64-bit executable arm64
```


### Overriding `CMAKE_OSX_ARCHITECTURES`


You can set this to a single value if you only want to target one architecture, for example: `set(CMAKE_OSX_ARCHITECTURES "arm64")`.


This variable can also be set from the command line by the user, allowing them to override the project's default.  Below, we configure an arm64-only binary:


```c++
//<ti>
cmake .. -DCMAKE_OSX_ARCHITECTURES=arm64
```


## Summary


Being able to adapt to the target hardware is a key part of writing truly portable build scripts. CMake provides clean, high-level variables that abstract away the low-level compiler flags needed to manage different architectures.

- **32-bit vs. 64-bit**: Use `if(CMAKE_SIZEOF_VOID_P EQUAL 8)` to detect 64-bit systems. This is the standard, portable way to check the target's pointer size.
- **Apple Universal Binaries**: On macOS, set the `CMAKE_OSX_ARCHITECTURES` variable to a list of architectures (e.g., `"x86_64;arm64"`) to build a single executable that runs natively on both Intel and Apple Silicon Macs.
- **Abstraction is Key**: Use these variables to define preprocessor macros or `INTERFACE` targets. This keeps the low-level detection logic in your `CMakeLists.txt` and presents a clean, abstract interface to your C++ code and consuming targets.

<Preview>


### Cross-Compilation and Toolchain Files


We've seen how to detect the architecture of the system we're building _for_. But what if the system we're building _on_ is different from the system we're building _for_?


In the next lesson, we will introduce **cross-compilation**. We'll learn about **toolchain files**, the standard CMake mechanism for describing a target platform, and see how they allow us to build for embedded devices, mobile phones, or other operating systems from a single development machine.


</Preview>


</Pw>

Rewrote "Creating 32 Bit Builds" section, and added new "Setting Instruction Sets" Section

`CMAKE_SIZEOF_VOID_P` Variable

`CMAKE_OSX_ARCHITECTURES` Variable

Building a Universal macOS Binary

64-bit computing

Difference between 32-bit and 64-bit operating systems

CMake: How to detect if I'm compiling for 32 or 64 bit?

CMake: How to build a universal binary for OSX?

CMake Cross Compiling

Master architecture-specific builds with CMake. This guide covers how to detect and handle 32-bit vs. 64-bit systems using CMAKE_SIZEOF_VOID_P and how to create Universal Binaries for macOS on Intel and Apple Silicon using CMAKE_OSX_ARCHITECTURES.

CMake for Different Architectures: 32-bit, 64-bit, and Apple Silicon

Handling Architecture (32-bit vs. 64-bit)

Practical Example: Architecture-Specific Macros

Creating 32-bit Builds with MSVC (Visual Studio)

macOS Architectures: Intel and Apple Silicon

Handling Different Architectures

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

Managing C++ Projects Using CMake