Managing CMake configurations across different environments (debug, release, Windows, Linux, macOS, CI/CD) can quickly become messy. Command-line variables and toolchain files are powerful, but they’re hard to share and standardize.
These become -D flags passed to CMake. They override values from inherited presets. Build presets reference a configure preset by name. The jobs field controls parallel build level. cmakepresets.json example
"buildPresets": [ "name": "dev-linux-gcc", "inherits": "default", "configurePreset": "dev-linux-gcc" ] When you run cmake --build --preset dev-linux-gcc , CMake automatically uses the binary directory from the corresponding configure preset. List available presets cmake --list-presets Output: They override values from inherited presets
1. Version and Minimum CMake Version "version": 6, "cmakeMinimumRequired": "major": 3, "minor": 23, "patch": 0 "buildPresets": [ "name": "dev-linux-gcc"
You can inherit from a hidden base, then from another preset, and finally override specific variables. Condition on build type "condition": "type": "equals", "lhs": "$envCI", "rhs": "true"
| Array | Purpose | |-------|---------| | "version" | Required – specifies preset file schema version. | | "configurePresets" | Defines cmake --configure options. | | "buildPresets" | Defines cmake --build options. | | "testPresets" | Defines ctest options. | | "packagePresets" | Defines cpack options (CMake 3.23+). | | "vendor" | IDE‑specific extensions (e.g., Visual Studio). |
Enter CMakePresets.json – a game-changing feature introduced in CMake 3.19 and continuously improved since. It allows you to define, version-control, and share build configurations in a single JSON file.