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

**Static analysis** is the process of analyzing code for potential errors without executing it.  Static analysis tools simply read our code files to see if they can find any potential issues.


A **linter** is a type of static analysis tool that checks for stylistic errors, common programming mistakes, and violations of best practices.


**Clang-Tidy** is a highly configurable linter for C++, C, and Objective-C. It can detect everything from simple formatting issues to complex bugs like potential memory leaks or incorrect API usage.


## Integrating Clang-Tidy


Clang-Tidy is part of the [LLVM Project](https://llvm.org/).  It's likely you already have it installed in your environment, particularly if you followed along with the earlier section on using <InlineLessonPromo url="cmake/cmake-using-clang-format" title="Using Clang-Format" description="Using the Clang-Format tool to automatically enforce a consistent coding style, and integrating it into our build using a custom CMake target">ClangFormat</InlineLessonPromo>.


You can verify Clang-Tidy is available in your environment in the usual way:


```c++
//<ti>
clang-tidy --version
```


```c++
//<o>
LLVM (http://llvm.org/):
  LLVM version 20.1.8
  Optimized build.
```


From our build scripts, we can find `clang-tidy` in the usual way, via `find_program()`:


<CodeViewer>


<CodeFile path="cmake/Tidy.cmake" status="New" defaultOpen>


```c++
cmake_minimum_required(VERSION 3.23)
find_program(CLANG_TIDY_EXE "clang-tidy")

if(CLANG_TIDY_EXE)
    message(STATUS "clang-tidy found: ${CLANG_TIDY_EXE}")
    set(CMAKE_CXX_CLANG_TIDY ${CLANG_TIDY_EXE}
      --warnings-as-errors=-*
    )
else()
    message(WARNING "clang-tidy not found!")
endif()
```


</CodeFile>


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


```c++
#<cmake>
cmake_minimum_required(VERSION 3.23)
project(Greeter)

include(cmake/Coverage.cmake)
include(cmake/Sanitize.cmake)
include(cmake/Tidy.cmake)#<h>

add_subdirectory(app)
add_subdirectory(greeter)

enable_testing()
add_subdirectory(tests)

add_subdirectory(benchmarks)
```


</CodeFile>


</CodeViewer>


```c++
//<ti>
cmake --preset default
```


```c++
//<o>
...
-- clang-tidy found: D:/msys64/clang64/bin/clang-tidy.exe
...
```


We can now use this program using the same techniques we covered previously, by invoking it within a <InlineLessonPromo url="cmake/cmake-custom-commands" title="Integrating Tools with `add_custom_command()`" description="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.">custom command</InlineLessonPromo> or encapsulating it within a <InlineLessonPromo url="cmake/custom-targets-and-build-utilities" title="Custom Targets and Build Utilities" description="Learn to create standalone, non-code targets using add_custom_target() for utility tasks like code formatting and documentation generation.">custom target</InlineLessonPromo>.


However, CMake is aware of ClangTidy by default, and we can use it within our build simply by setting the `CMAKE_CXX_CLANG_TIDY` variable. This tells CMake to run `clang-tidy` alongside the compiler for every source file:


<CodeFile path="cmake/Tidy.cmake" status="Updated">


```c++
cmake_minimum_required(VERSION 3.23)
find_program(CLANG_TIDY_EXE "clang-tidy")

if(CLANG_TIDY_EXE)
    message(STATUS "clang-tidy found: ${CLANG_TIDY_EXE}")
    set(CMAKE_CXX_CLANG_TIDY ${CLANG_TIDY_EXE})
else()
    message(WARNING "clang-tidy not found!")
endif()
```


</CodeFile>


If we configure and build now, then we may already see some clang-tidy warnings, depending on the state of our code base:


```c++
//<ti>
cmake --preset default
```


```c++
//<ti>
cmake --build --preset default
```


```c++
//<o>
warning: Value stored to '_' during its initialization is never read [clang-analyzer-deadcode.DeadStores]
   10 |   for (auto _ : state) {
      |             ^ ~
```


## Suppressing Warnings


In large projects, linters will often output warnings or errors for sections of code that we're happy with, or don't want to refactor.  To handle this, we can suppress the linter by adding specifically formated comments at or near the offending lines.


Adding a `NOLINT` comment will ask the linter to ignore that line:


<CodeFile path="benchmarks/bench_main.cpp">


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

static void BM_Greeter_Greet(benchmark::State& state) {
  std::string name(state.range(0), 'x');
  Greeter g(name);

  for (auto _ : state) {// NOLINT//<h>
    std::string result = g.greet();
    benchmark::DoNotOptimize(result);
  }
}

BENCHMARK(BM_Greeter_Greet)->Range(8, 32768);

BENCHMARK_MAIN();
```


</CodeFile>


We can also ask the linter to ignore the **next** line using `NOLINTNEXTLINE`:


```c++
// NOLINTNEXTLINE //<h>
for (auto _ : state) {
  std::string result = g.greet();
  benchmark::DoNotOptimize(result);
}
```


We can ignore an entire block by wrapping it between `NOLINTBEGIN` and `NOLINTEND` comments:


```c++
// NOLINTBEGIN //<h>
for (auto _ : state) {
  std::string result = g.greet();
  benchmark::DoNotOptimize(result);
}
// NOLINTEND //<h>
```


All of these `NOLINT` variations allow us to specify the rule we want to suppress within brackets.  The name of the rull that was violated will be included in the warning or the error that was emitted:


```c++
// NOLINTNEXTLINE(clang-analyzer-deadcode.DeadStores)//<h>
for (auto _ : state) {
  std::string result = g.greet();
  benchmark::DoNotOptimize(result);
}
```


This is generally recommended, as it clarifies to readers what the comment is actually suppressing.


Additionally, if a new violation is added to the area, that new violation will emit a warning to attract our attention, rather than also get suppressed.


We can suppress multiple rules by comma-seperating them:


```c++
// NOLINTNEXTLINE(rule-1,rule-2)
```


## Configuring Clang-Tidy


Clang-Tidy is highly configurable.  The primary way of doing this is through a `.clang-tidy` file - note the initial `.` in the file name.  This file is stored in your project root and shared among the team.


The most notable thing we configure is which rules we want Clang-Tidy to check for.  Clang-Tidy can scan for around 300 issue at the time of writing.  You can find them all on the [official documentation](https://clang.llvm.org/extra/clang-tidy/checks/list.html).


Let's enable a check that suggests using `nullptr` instead of the old `NULL` macro:


<CodeFile path=".clang-tidy" status="New">


```yaml
Checks: '-*,modernize-use-nullptr'
```


</CodeFile>


The `-*` syntax tells Clang-Tidy to disable all checks.  The following `modernize-use-nullptr` then tells it to renable checking for just that rule.


We can add further rules using comma-separation.  The following configuration also discourages the use of `std::endl`:


```yaml
Checks: '-*,modernize-use-nullptr,performance-avoid-endl'
```


Let's introduce some code that violates the `modernize-use-nullptr`. Historically, the `NULL` keyword was often used to represent null pointers.  `NULL` is a macro typically defined as the integer `0`.  


Setting a pointer to `0` technically works as a way to represent a null pointer, but it causes issues in overload resolution:


```c++
void f(int); 
void f(char*);

f(NULL); // calls f(int), not f(char*) //<w>
```


C++11 introduced the explicit `nullptr` keyword, which is now the best practice:


```c++
void f(int); 
void f(char*);

f(nullptr); // calls f(char*) //<h>
```


We'll violate this rule in `Greeter.cpp` so we can confirm that our configuration is working:


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


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

Greeter::Greeter(std::string name)
  : name_(std::move(name)) {}

std::string Greeter::greet() const {
  int* SomePtr{NULL};//<w>
  return "Hello, " + name_ + "!";
}
```


</CodeFile>


Let's rebuild our project:


```c++
//<ti>
cmake --build --preset default
```


During compilation, Clang-Tidy should run and emit a warning directly in our build log, pointing out the violation and often suggesting a fix:


```c++
//<o>
.../greeter/src/Greeter.cpp:20:13: warning: use nullptr [modernize-use-nullptr]
  if (ptr == NULL) {
             ^
             nullptr
```


### Emitting Errors


Our previous rule emits a **warning** when violations are detected.  If we care a lot about ensuring a specific rule is followed, we can upgrade that to an **error** instead.  We can do this using the WarningAsErrors option in our `.clang-tidy`:


<CodeFile path=".clang-tidy">


```yaml
Checks: '-*,modernize-use-nullptr'

# Treat specific warnings as errors:
WarningsAsErrors: 'modernize-use-nullptr'

# Alternatively, treat all warnings as errors:
WarningsAsErrors: '*'
```


</CodeFile>


If we rebuild the project, our use of `NULL` over `nullptr` should now generate an error.


Our build system may skip rebuilding our targets if the only thing that has changed is a `.clang-tidy` file.  We can delete our outputs and force them to be recompiled by passing the `--clean-first` argument:


```c++
//<ti>
cmake --build --preset default --clean-first
```


```c++
//<oe>
D:/Projects/cmake/greeter/src/Greeter.cpp:7:16: error: use nullptr [modernize-use-nullptr,-warnings-as-errors]
    7 |   int* SomePtr{NULL};
      |                ^~~~
      |                nullptr

1 warning treated as error
```


### Configuring Clang-Tidy using Variables


We can configure Clang-Tidy by extending our use of the `CMAKE_CXX_CLANG_TIDY` variable.  This approach would override any rules we had set in our `.clang-tidy` file, if we had one.


For example, to override the warnings-as-errors configuration we set in our `.clang-tidy`, we could set that argument to `-*`, removing the errors for all rules:


<CodeFile path="cmake/Tidy.cmake" status="Updated">


```c++
#<cmake>
cmake_minimum_required(VERSION 3.23)
find_program(CLANG_TIDY_EXE "clang-tidy")

if(CLANG_TIDY_EXE)
  message(STATUS "clang-tidy found: ${CLANG_TIDY_EXE}")
  set(CMAKE_CXX_CLANG_TIDY ${CLANG_TIDY_EXE}
    --warnings-as-errors=-*#<h>
  )
else()
  message(WARNING "clang-tidy not found!")
endif()
```


</CodeFile>


As with any variable, this could also be set from a preset:


<CodeFile path="CMakePresets.json" status="Updated">


```json
{
  "version": 3,
  "configurePresets": [
    // ... other presets
    {
      "name": "no-lint-errors",
      "inherits": "default",
      "cacheVariables": {
        "CMAKE_CXX_CLANG_TIDY":
          "clang-tidy;--warnings-as-errors=-*"
      }
    }
  ]
  // ... 
}
```


</CodeFile>


<Pw>


## Practical Example: Performance Checks


Finally, let's cover a slightly more advanced configuration.  It's a common mistake in C++ to pass a large object, like a `std::string`, to a function **by value** when it could be passed **by** **`const`** **reference**. Passing by value creates an unnecessary and potentially expensive copy.


First, let's update our `.clang-tidy` with some further checks.  Our previous configuration was checking for violations of the `modernize-use-nullptr` rule.  The preference for using `nullptr` relates to code modernization, so it is prefixed with the `modernize-` tag.  All other rules are namespaced in similar ways.  For example:

- Checks that relate to performance have a name starting with `performance-`
- Checks relating to general code reability start with `readability-`
- Checks that scan for syntax that is a common source of bugs are prefixed with `bugprone-`

We can use this to configure large categories of checks at once.  The following config file enables all checks relating to modernization and performance.  It also specifically upgrades violations of the unnecessary passing-by-value rule to be errors:


<CodeFile path=".clang-tidy" status="Updated">


```yaml
Checks: '-*,modernize-use-nullptr,performance-*'
WarningsAsErrors: 'performance-unnecessary-value-param'
```


</CodeFile>


Let's update `Greeter.cpp` to make this mistake:


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


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

Greeter::Greeter(std::string name)
  : name_(std::move(name)) {}

namespace {
bool should_ignore(std::string name) {//<w>
  return name == "Bob";
}
}

std::string Greeter::greet() const {
  if (should_ignore(name_)) return "";//<h>
  return "Hello, " + name_ + "!";
}
```


</CodeFile>


Now, when we build, Clang-Tidy will analyze `Greeter.cpp`. Because we set `WarningsAsErrors` for the rule we just violated, the check will fail the build and provide a detailed message explaining the problem and suggesting the fix.


```c++
//<oe>
Greeter.cpp:7:32: warning: the parameter 'name' is copied for each invocation but only used as a const reference; consider making it a const reference [performance-unnecessary-value-param]
    7 | bool should_ignore(std::string name) {
      |                                ^
      |                    const      &
```


Remember, we now also have benchmarks to quantify this problem.  Previously, the `BM_Greeter_Greet/32768` benchmark was reporting around 1,500 ns on my machine.


With our latest changes, the run time of our `greet()` function has increased by around 60%:


```c++
//<ti>
cmake --build --preset release
```


```c++
//<ti>
./build/benchmarks/GreeterBenchmarks
```


```c++
//<o>
------------------------------------------------------
Benchmark                   Time      CPU   Iterations
------------------------------------------------------
...
BM_Greeter_Greet/32768   2440 ns  2382 ns       295153
```


If we do what Clang-Tidy suggests and update it to use a `const` reference, our new feature only adds around 15%:


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


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

Greeter::Greeter(std::string name)
  : name_(std::move(name)) {}

namespace {
bool should_ignore(const std::string& name) {//<h>
  return name == "Bob";
}
}

std::string Greeter::greet() const {
  if (should_ignore(name_)) return "";
  return "Hello, " + name_ + "!";
}
```


</CodeFile>


```c++
//<ti>
cmake --build --preset release
```


```c++
//<ti>
./build/benchmarks/GreeterBenchmarks
```


```c++
//<o>
-------------------------------------------------------
Benchmark                   Time       CPU   Iterations
-------------------------------------------------------
...
BM_Greeter_Greet/32768   1722 ns   1713 ns       401408
```


Clang-Tidy has hundreds of checks covering performance, readability, modern C++ idioms, and more. You can find a full list and detailed explanations on the [official Clang-Tidy documentation page](https://clang.llvm.org/extra/clang-tidy/checks/list.html).


## Other Analysis Tools


The tools we've covered are just the beginning. The C++ ecosystem has a huge set of analysis tools, and most can be integrated into CMake using the patterns we've learned. Here are a few more to be aware of:


### Dependency Analysis


Over time, `#include` directives in C++ files tend to become a mess. You might include headers you don't need, or forget to include headers you do need (relying on them being included transitively).


`include-what-you-use` (IWYU) is a tool that analyzes your code and tells you exactly which headers you should add or remove, helping to keep your codebase clean and improve compilation times.


### Security Analysis


Many static analysis tools, including commercial ones like SonarQube and advanced configurations of Clang-Tidy, can be used to scan for common security vulnerabilities.


## Summary


In this lesson, we explored static analysis as the final pillar of our automated code quality toolkit.

- **Static Analysis**: Tools that analyze code for bugs and style issues without executing it.
- **Clang-Tidy**: A powerful, configurable linter for C++. We integrated it into our build by setting the `CMAKE_CXX_CLANG_TIDY` variable.
- **Configuration as Code**: The behavior of Clang-Tidy is controlled by a `.clang-tidy` file in the project root, allowing you to define and share a consistent set of checks for the whole team.
- **Enforcing Quality**: We saw how Clang-Tidy can automatically find performance pitfalls and suggest modern C++ idioms like `nullptr`.
- **Advanced Clang-Tidy Capabilities**: This is only the tip of the iceberg of what Clang-Tidy can help with.  The [official documentation page](https://clang.llvm.org/extra/clang-tidy/checks/list.html) has much more.

<Preview>


### Continuous Integration, Packaging, and Deployment


We have now assembled a complete local development workflow. We can build our code, run tests, check for memory errors, benchmark performance, and enforce coding standards, all with simple, automated commands.


The next and final step is to take this local workflow and automate it for the entire team. In the next chapter, we will introduce **Continuous Integration (CI)**. We'll learn how to use a build server like **GitHub Actions** to automatically run our build, tests, and analysis on every code change, ensuring that our project remains in a high-quality state at all times.


</Preview>


</Pw>

Style Guides and Automatic Code Formatting

Static Analysis

Clang-Tidy Documentation

List of Clang-Tidy Checks

`CMAKE_CXX_CLANG_TIDY` Variable

Include What You Use (IWYU)

Finding Bugs with Clang Static Analysis - Gabor Horvath

A practical guide to integrating the Clang-Tidy static analysis tool with CMake. Learn to set up a .clang-tidy configuration, enable checks via the CMAKE_CXX_CLANG_TIDY variable, and automatically find bugs and style issues during compilation.

Automating C++ Code Quality with CMake and Clang-Tidy

Continuous Integration, Packaging, and Deployment

Using Clang-Tidy

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

Managing C++ Projects Using CMake