CMake overview: one build description for every toolchain
What CMake is
CMake is not a compiler and not a build tool. It is a build system generator: you describe how a project is organised in CMakeLists.txt files, and CMake writes the project files that a native tool such as Ninja, Visual Studio, Xcode or Make then executes. That indirection is the whole point. One description can drive MSBuild on Windows, Makefiles on a build server and a cross-compilation toolchain for an embedded target, which is why the C and C++ ecosystem leans on it so heavily. The project is BSD 3-Clause licensed and ships with supporting tools including CTest for tests, CPack for packaging and cmake-gui for users who prefer dialogs to flags.
The configure and build workflow
Work is separated into two stages. Configuration reads the CMakeLists.txt files, probes the compiler and writes a cache with the resolved settings. Generation then produces the native project files. In practice you run one command to configure into a separate build directory and a second to build: cmake -S . -B build -G Ninja followed by cmake --build build. Installation and packaging run through the same tool, for example cmake --install build --prefix /some/where. Cache variables such as CMAKE_BUILD_TYPE or CMAKE_INSTALL_PREFIX are set with -D at configure time, and presets files let a team share those settings instead of documenting long command lines.
Settings, limits and things that surprise people
Out-of-source builds are the norm: keeping the build tree separate from the source tree avoids stale artefacts and makes a clean rebuild as simple as deleting one directory. CMake does not compile anything by itself, so a compiler and a generator must already be present and the chosen generator must be installed. Older projects that request an old minimum version produce policy warnings, and raising that minimum can change behaviour, so it is a deliberate edit rather than routine housekeeping. The scripting language is large, and its target and usage-requirement model takes real study; newcomers often find the first project harder than the code it builds.
When to choose something else
For a handful of files compiled with one compiler, a two-line Makefile or a script is simpler and easier to explain. Projects in a language with its own build tool should use that tool rather than wrapping it in CMake. If the pain point is specifically the DSL, lighter generators cover many C and C++ projects with less ceremony. CMake earns its place when a project must build across several platforms, toolchains and IDEs from one description.
- Best for
- C and C++ developers who need one build description that works across several compilers, platforms and IDEs.
- Good to know
- CMake generates build files but does not compile, so a compiler and a generator such as Ninja or Visual Studio must already be installed.
How to get started
- Download the Windows installer and run it; during setup choose whether CMake is added to the system PATH.
- Verify the install in a new terminal with
cmake --version, which also confirms the PATH entry works. - Put a CMakeLists.txt in your project root that sets a minimum version, a project name and at least one target.
- Configure out of source with
cmake -S . -B build -G Ninja, adding -D options for cache values you want to change. - Build with
cmake --build build, and install withcmake --install build --prefix <dir>when you need a staged layout.
Questions & answers
Does CMake compile my code?
No. It writes project files for a generator, and that generator drives the compiler. You need a compiler and a generator such as Ninja, Make or Visual Studio installed.
Why do I get policy warnings on an old project?
The project requests an older minimum version, so CMake keeps legacy behaviour. Raising the minimum version modernises the build but can change results, so test the change.
Where should the build directory live?
Outside the source tree. A separate build directory keeps generated files out of version control and lets you delete it for a clean rebuild.