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, our build scripts have lived in a self-contained world. They define targets, link libraries, and set options, but they haven't needed to interact much with the world outside their own `CMakeLists.txt` files.


Real-world build processes, however, are rarely so isolated. They often need to:

- Read configuration data from external files.
- Find source files automatically.
- Generate code or configuration headers.
- Copy assets and resources into the build directory.

To accomplish these tasks, our scripts need to be able to read, write, and manipulate files and directories on the disk. This lesson introduces the primary tool for all such operations: the versatile `file()` command.


## Working with Paths


Before we work with files, it's worth understanding how to work with their paths. CMake provides several built-in variables and a `get_filename_component()` command for this purpose.


### Essential Path Variables


We've seen some of these before, but it's worth summarizing them here. These variables help you refer to key locations in your project in a portable way:

- `CMAKE_SOURCE_DIR` / `PROJECT_SOURCE_DIR`: The absolute path to the top-level source directory (where the root `CMakeLists.txt` is).  These variables are often the same, but there is a subtle difference within builds that contain multiple `project()` commands.  We'll cover this later.
- `CMAKE_BINARY_DIR` / `PROJECT_BINARY_DIR`: CMake uses the "binary directory" name for what most developers call the build directory. These variables stores the absolute path to the top-level build directory - where you ran the `cmake` command.   Again, they are usually the same, but there is a subtle difference when we have multiple `project()` commands.
- `CMAKE_CURRENT_SOURCE_DIR`: The absolute path to the source directory containing the `CMakeLists.txt` file that is _**currently being processed**_. This will be different from `CMAKE_SOURCE_DIR` when it is used in a `CMakeLists.txt` file that was loaded through the `add_subdirectory()` command.
- `CMAKE_CURRENT_BINARY_DIR`: The absolute path to the build directory corresponding to the current source directory.  Again, this will be different to `CMAKE_BINARY_DIR` within the `add_subdirectory()` context.

### Manipulating Paths with `get_filename_component()`


This command is CMake's primary tool for dissecting and manipulating path strings. It can extract the directory, the filename, the extension, and more.


The basic syntax is:


```c++
#<cmake>
get_filename_component(<variable> <path> <component>)
```


Let's see it in action. Imagine we have a variable holding a full path to a file:


```c++
#<cmake>
set(FULL_PATH "/path/to/my/file.txt")
```


We can extract different parts:


```c++
#<cmake>
set(FULL_PATH "/path/to/my/file.txt")

get_filename_component(PARENT_DIR ${FULL_PATH} DIRECTORY)
# PARENT_DIR is now "/path/to/my"

get_filename_component(FILENAME ${FULL_PATH} NAME)
# FILENAME is now "file.txt"

get_filename_component(FILE_EXT ${FULL_PATH} EXT)
# FILE_EXT is now ".txt"

get_filename_component(NAME_NO_EXT ${FULL_PATH} NAME_WE)
# NAME_NO_EXT is now "file"
```


This is useful when you need to programmatically construct new paths based on existing ones, such as creating an output file with the same name as an input file but with a different extension.


<Pw>


## The `file()` Command


The `file()` command is one of the most flexible commands in CMake. It's a single command that provides a huge collection of subcommands for different file-related tasks. The general syntax is:


```c++
file(<SUBCOMMAND> ...arguments...)
```


We can broadly categorize these subcommands into three groups:

- **Reading**: Getting content from files on disk.
- **Writing**: Creating new files or modifying existing ones.
- **Filesystem Operations**: Creating directories, copying files, and finding files that match a pattern.

Let's explore each of these categories.


## Reading from Files


Sometimes, you want to store project information outside of your `CMakeLists.txt` file. For example, you might have a simple text file containing your project's version number. The `file()` command lets you read this data directly into a CMake variable.


### `file(READ)`


This subcommand reads the entire content of a file into a single variable.


Let's create a `version.txt` file in the root of our `Greeter` project:


<CodeFile path="version.txt" status="New">


```plain text
1.2.3
```


</CodeFile>


Now, we can modify our root `CMakeLists.txt` to read this version instead of hardcoding it.  This pattern makes it easy to manage configuration data in separate, simple files that non-programmers can edit.


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


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

# Read the version.txt file
# Store it in avariable called GREETER_VERSION_FROM_FILE
file(READ version.txt GREETER_VERSION_FROM_FILE) #<h>

# Strip any excess white space from GREETER_VERSION_FROM_FILE,
# Then store the result in a variable called GREETER_VERSION
string(STRIP ${GREETER_VERSION_FROM_FILE} GREETER_VERSION) #<h>

message(STATUS "Configuring Version ${GREETER_VERSION}")#<h>

project(
  Greeter
  VERSION ${GREETER_VERSION} #<h>
  HOMEPAGE_URL "https://www.studyplan.dev"
  DESCRIPTION "A program that says hello to people"
)

# ...
```


</CodeFile>


```c++
//<o>
-- Configuring Version 1.2.3
```


Our initial `file()` command reads the content of `version.txt` and stores it in the `GREETER_VERSION_FROM_FILE` variable. This variable will likely contain additional white space - possibly a new line, such as `"1.2.3\n"`.


`string(STRIP ...)` is a handy utility command that removes leading and trailing whitespace. We use it to clean up the variable, so `GREETER_VERSION` becomes just `"1.2.3"`.


### `file(STRINGS)`


While `file(READ)` grabs the whole file, `file(STRINGS)` is more specific: it reads a file and splits it into a CMake list, with each line of the file becoming an element in the list.


This is perfect for when you have a manifest file listing items, such as a list of source files. Let's imagine we have a file called `sources.txt` in our `app` directory:


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


```plain text
src/main.cpp
src/tools.cpp
```


</CodeFile>


We can now read this into a list variable in `app/CMakeLists.txt`:


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


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

file(STRINGS sources.txt SOURCES) #<h>
foreach(file IN LISTS SOURCES)
  message(STATUS "Using file ${file}")
endforeach()

project(MyProject)
add_executable(MyTarget SOURCES)
```


</CodeFile>


```c++
//<o>
-- Using file src/main.cpp
-- Using file src/tools.cpp
```


The `SOURCES` variable will now be the list `"src/main.cpp;src/goodbye.cpp"`, which is then correctly expanded when passed to `add_executable()`. This approach can make it easier to manage long lists of files without cluttering your main `CMakeLists.txt`.


## Writing to Files


Just as we can read from files, we can also write to them. This is often used for generating files at configure time, such as a build information file or a configuration header.


### `file(WRITE)` and `file(APPEND)`


These commands are straightforward: `WRITE` creates a new file (or overwrites an existing one), and `APPEND` adds content to the end of a file.


Let's create a simple command that generates a `build_info.txt` file containing the timestamp of when the project was configured. We'll use the `string(TIMESTAMP)` command to get the current time.


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


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

project(MyProject VERSION "1.2.3")

string(TIMESTAMP BUILD_TIME "%Y-%m-%d %H:%M:%S UTC") #<h>
set(BUILD_INFO "Project: ${PROJECT_NAME}\n") #<h>
set(BUILD_INFO "${BUILD_INFO}Version: ${PROJECT_VERSION}\n") #<h>
set(BUILD_INFO "${BUILD_INFO}Configured at: ${BUILD_TIME}\n") #<h>

file(WRITE ${CMAKE_BINARY_DIR}/build_info.txt "${BUILD_INFO}") #<h>
message(STATUS "Wrote build info to ${CMAKE_BINARY_DIR}")
```


</CodeFile>


In this example, we're using the CMake-provided `CMAKE_BINARY_DIR` variable.  CMake's "binary directory" is what most developers call the "build directory" - that is, the directory from which we used our `cmake` command.


So, in this case, when we configure our project, this will create a `build_info.txt` file in our `build` directory:


```c++
//<o>
-- Wrote build info to D:/projects/cmake/build
```


<CodeFile path="build/build_info.txt" status="Generated">


```plain text
Project: MyProject
Version: 1.2.3
Configured at: 2025-07-29 23:19:09 UTC
```


</CodeFile>


An interesting use of this technique is to create C++ header files within CMake, and to then `#include` those headers as needed in our source files.


This gives our program access to information that is normally only available within a `CMakeLists.txt` script.  We'll see a practical example of this later in the course.


## Filesystem Operations


The `file()` command also provides tools for manipulating the filesystem itself, such as creating directories and copying files.


### Using `file(GLOB)` and `file(GLOB_RECURSE)`


This is one of the most tempting, and most dangerous, subcommands in CMake. `GLOB` allows you to find all files in a directory that match a certain pattern (a "globbing expression") and store them in a list.


For example, to find all `.cpp` files in the `src` directory, you could write:


```c++
#<cmake>
file(GLOB GREETER_SOURCES "src/*.cpp")
add_executable(GreeterApp ${GREETER_SOURCES})#<w>
```


This looks incredibly convenient. You never have to manually update your `CMakeLists.txt` when you add or remove a source file. However, this convenience comes at a high price.


<Error>


### The Problem with `file(GLOB)`


**Do not use** **`file(GLOB)`** **to collect source files.**


This is a fundamental rule of modern CMake. The reason is subtle but important: CMake is a build system _generator_. It runs once to generate native build files (like a `Makefile`). The native build system (like `make`) then uses that generated file to compile your code.


The `file(GLOB)` command is only executed when CMake runs. If you add a new source file to your `src` directory, the `Makefile` has no idea it exists. Running `make` will not compile the new file. The `Makefile` is stale. To make it see the new file, you must remember to manually re-run `cmake ..` to regenerate the build system.


This breaks the reliability of the build process and is a common source of "it works on my machine" bugs, especially in teams where a developer might forget this extra step.


Always list your source files explicitly. It's more work, but it's robust and reliable.


```c++
#<cmake>
# GOOD: Explicitly list your sources.
set(GREETER_SOURCES
  src/main.cpp
  src/Greeter.cpp
)

add_library(GreeterLib ${GREETER_SOURCES})
```


</Error>


### Creating Directories


The `file(MAKE_DIRECTORY)` subcommand ensures that one or more directories exist, creating them if they don't. It's useful in custom build steps where you need to guarantee an output directory is present before copying files into it.


```c++
#<cmake>
# Ensure an assets directory exists in the build folder
file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/assets)
```


### Copying Files


The `file(COPY)` subcommand copies files or entire directories from a source to a destination. It's a simple way to move resources needed at runtime into your build directory.


```c++
#<cmake>
# Copy a config file into the build directory
file(COPY "data/config.json" DESTINATION ${CMAKE_BINARY_DIR}/)
```


## Practical Example: Copying Assets


A very common use case for file operations is managing non-code assets that your application needs at runtime, such as images, configuration files, or fonts. You typically want to copy these assets from your source tree into your build directory so that they are available alongside your executable.


Let's extend our `Greeter` project to handle this.


### Step 1: Create the Asset Files


First, let's create an `assets` directory in our project's root and add a couple of files.  It doesn't matter what these files are or what they contain, we're just going to use them as placeholders to learn the process:


```plain text
//<nh>
assets/
  ├─ logo.png
  └─ config.json
CMakeLists.txt
```


### Step 2: Update CMakeLists.txt to Copy the Files


Now, let's add logic to our root `CMakeLists.txt` to copy these files into the build directory. We will use a combination of `set()`, `foreach()`, and `file()` commands.


<CodeFile path="CMakeLists.txt">


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

set(ASSET_FILES
  logo.png
  config.json
)

set(ASSET_DEST "${CMAKE_BINARY_DIR}/assets")

# Ensure the destination directory exists
file(MAKE_DIRECTORY ${ASSET_DEST})

foreach(asset IN LISTS ASSET_FILES)
  # Build the full path to the current asset file 
  set(src_path "${CMAKE_CURRENT_SOURCE_DIR}/assets/${asset}")
   
  # Copy the source file to the destination directory.
  file(COPY ${src_path} DESTINATION ${ASSET_DEST})
   
  message(STATUS "Copied ${src_path} to asset directory")
endforeach()
```


</CodeFile>


### Step 3: Verify the Result


Now, when you run the configure step (`cmake ..` from your `build` directory), this script will execute.


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


```c++
//<o>
-- Copied D:/Projects/cmake/assets/logo.png to asset directory
-- Copied D:/Projects/cmake/assets/config.json to asset directory
```


Afterward, your build directory will have a new, populated `assets` folder, ready for your executable to use.


```c++
build/
├─ assets/
│  ├─ logo.png
│  └─ config.json
├─ ... (other generated files)
```


<Preview>


### Installers and Packaging using CPack


Shuffling files around to prepare our software to be shipped is an extremely common requirement, and this is only one implementation of it.  Often, those implementations use some or all of these adjustments:

1. Don't copy assets that are already in the build directory and haven't changed
2. Copy assets only when the build is successful, rather than as part of the configure step
3. Rather than copying the assets to the build directory, copy the build output to where the assets are.  This is common if our project has a lot of assets, or if those assets are large files that take a while to copy.

We'll learn the techniques required to make all of these adjustments later in the course.


We'll also cover the packaging process in general, which includes creating installers and similar mechanisms to distribute our software.  CMake includes the CPack tool to help with this.


</Preview>


## Summary


The `file()` command is an important part of any non-trivial CMake script. It's your bridge between the abstract world of build targets and the concrete world of files and directories on disk.

- **Reading**: Use `file(READ)` to get a file's full content and `file(STRINGS)` to read it line-by-line into a list.
- **Writing**: Use `file(WRITE)` and `file(APPEND)` to generate files at configure time.
- **Filesystem**: Use `file(MAKE_DIRECTORY)` and `file(COPY)` for basic filesystem management.
- **Avoid** **`file(GLOB)`**: Never use `file(GLOB)` to collect source files; it makes your build unreliable. Always list sources explicitly.
- **Path Management**: Understand the key path variables (`CMAKE_SOURCE_DIR`, `CMAKE_CURRENT_SOURCE_DIR`, etc.) and use `get_filename_component()` for all your path manipulation needs.

<Preview>


### Modularizing CMake Code


We've learned a lot about the CMake scripting language, including variables, lists, control flow, and file manipulation. As our `CMakeLists.txt` files get more complex, we'll want to apply the same principles of good software design to them: breaking down logic into smaller, reusable pieces.


In the next lesson, we will explore how to create functions and macros in CMake. This will allow us to encapsulate complex logic, reduce code duplication, and create clean, high-level APIs for our build scripts.


</Preview>


</Pw>

`file()` Command Documentation

`get_filename_component()` Command Documentation

`string()` Command Documentation

Why is cmake file GLOB evil?

Is GLOB still considered harmful with CONFIGURE_DEPENDS?

CMake Variables Manual

Master filesystem operations in CMake with this comprehensive guide. Learn to use the file() command to read, write, and find files, manage paths with built-in variables, and understand the pitfalls of file(GLOB).

File System Operations

Manipulating Paths with `get_filename_component()`

Using `file(GLOB)` and `file(GLOB_RECURSE)`

Step 2: Update CMakeLists.txt to Copy the Files

Working with the File System

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

Managing C++ Projects Using CMake