CMake

Notes

Its adoption by Zephyr and by the Arm ecosystem largely displaced hand-maintained IDE project files in new SDKs.

Overview

CMake is an open source, cross-platform build system generator: it reads a project's CMakeLists.txt files and writes the native build scripts, such as Ninja or Makefiles, that actually compile the code. Embedded teams use it to describe a firmware or SDK build once and run it on Windows, Linux or macOS hosts with whichever cross-compiler the target needs. CMake does not compile anything itself; the generated scripts call the compiler and linker.

How it works

A CMake build runs in two phases. In the configure phase, CMake executes the project's CMakeLists.txt scripts, which declare targets such as executables and libraries, their source files, include paths and dependencies, and builds an internal model of the project. It then generates scripts for a chosen generator, most often Ninja or Make. In the build phase, those scripts do the compiling and linking, and they can usually be rerun after a source change without configuring again.

For cross-compiling, a toolchain file is passed at configure time. It names the target system (Generic for bare-metal targets with no operating system), the target processor, the compiler to use and, for Linux targets, a sysroot holding the target's headers and libraries. Settings in the file stop CMake from picking up host libraries by mistake. Because some embedded toolchains cannot link a test program without a linker script, CMake can be told to check the compiler using a static library instead.

SDKs often wrap CMake in their own tools. Zephyr generates Ninja or Make files through CMake and also processes devicetree and Kconfig inputs during configuration, and Espressif's ESP-IDF uses a CMake-based build system driven by its idf.py script. The trade-off is that CMake's own scripting language takes time to learn, and large projects need discipline to stay maintainable.

Examples

• A Zephyr application built with CMake generating Ninja files, with devicetree and Kconfig processed during the configure step.
• An ESP-IDF project built through idf.py, which wraps CMake and Ninja for the developer.
• A microcontroller SDK that ships a toolchain file for a bare-metal Arm GCC compiler and another for a commercial compiler.
• A continuous integration server configuring the same firmware for several boards by passing a different toolchain file and options each time.

Why it matters

Build and SDK engineers at chip vendors use CMake to give customers one build that works across host operating systems and compilers, and firmware developers depend on it every day. A clean toolchain file and target structure decides how easily a customer can drop vendor drivers into their own product.

In the chip lifecycle, CMake projects are set up during pre-silicon software development, used for bring-up and validation firmware, shipped inside SDKs at production, and maintained through each SDK release.

It matters most to: Build and CI Infrastructure Engineer, Embedded Software Engineer, MCU Software and SDK Engineer, SDK Engineer, Software Configuration and Build Engineer

Common confusions

Not the same as Make

Make runs build rules from a Makefile. CMake sits one level above and can generate those Makefiles, or Ninja files instead.

Not the same as Kconfig

Kconfig selects which features and options are built in, as in the Linux kernel and Zephyr. CMake describes how the selected sources are compiled and linked; in Zephyr the two work together.

Not the same as a compiler

CMake finds and calls a compiler such as GCC or Clang but does not translate code itself, so compiler errors come from the compiler, not from CMake.

Sources

1. cmake-toolchains(7) (opens in a new tab), Kitware (CMake documentation), 2026-10-22
2. About CMake (opens in a new tab), Kitware, 2026-10-22
3. Build System (CMake) (opens in a new tab), Zephyr Project, 2026-10-22
4. ESP-IDF Programming Guide: Build System (opens in a new tab), Espressif Systems, 2026-10-22

Related terms

• Kconfig
• west
• Cross-compiler

Where it appears on the Hub

Used on 12 pages of the Hub. In each group, the pages that mention it most come first.