CMAKE-PRESETS(7)

📦
version 4.4.5 · 21 versions
, in arch rolling

✨ NAME ✨

CMAKE-PRESETS(7) — cmake-presets — CMake Presets Reference 💖

Okay bestie, welcome to the CMAKE-PRESETS(7) glow-up. This is literally the whole CMake Presets Reference, and we are keeping every single detail. Buckle up 🎀

🌸 INTRODUCTION 🌸

Added in version 3.19.

So here’s the vibe: one problem that CMake users often face is sharing settings with other people for common ways to configure a project. Maybe it’s to support CI builds, maybe it’s for users who frequently use the same build — either way, CMake supports two main files, CMakePresets.json and CMakeUserPresets.json, that allow users to specify common configure options and share them with others. 🫶

Added in presets version 4: CMake also supports files included with the include field. See Includes for more details.

CMakePresets.json and CMakeUserPresets.json live in the project’s root directory. They both have exactly the same format, and both are optional (though at least one must be present if --preset <#cmdoption-cmake-preset> is specified). CMakePresets.json is meant to specify project-wide build details, while CMakeUserPresets.json is meant for developers to specify their own local build details.

CMakePresets.json may be checked into a version control system, and CMakeUserPresets.json should NOT be checked in. For example, if a project is using Git, CMakePresets.json may be tracked, and CMakeUserPresets.json should be added to the .gitignore.

Added in version 4.4: CMake also supports specifying a file from which to read presets via the --presets-file <#cmdoption-cmake-presets-file> option. If this option is specified, neither of CMakePresets.json nor CMakeUserPresets.json are required to be present, and any presets defined in those files will be ignored/unavailable.

🌈 FORMAT 🌈

The files are a JSON document with an object as the root:

          {
            "version": 10,
            "cmakeMinimumRequired": {
              "major": 3,
              "minor": 23,
              "patch": 0
            },
            "$comment": "An example CMakePresets.json file",
            "include": [
              "otherThings.json",
              "moreThings.json"
            ],
            "configurePresets": [
              {
                "$comment": [
                  "This is a comment row.",
                  "This is another comment,",
                  "just because we can do it"
                ],
                "name": "default",
                "displayName": "Default Config",
                "description": "Default build using Ninja generator",
                "generator": "Ninja",
                "binaryDir": "${sourceDir}/build/default",
                "cacheVariables": {
                  "FIRST_CACHE_VARIABLE": {
                    "type": "BOOL",
                    "value": "OFF"
                  },
                  "SECOND_CACHE_VARIABLE": "ON"
                },
                "environment": {
                  "MY_ENVIRONMENT_VARIABLE": "Test",
                  "PATH": "$env{HOME}/ninja/bin:$penv{PATH}"
                },
                "vendor": {
                  "example.com/ExampleIDE/1.0": {
                    "autoFormat": true
                  }
                }
              },
              {
                "name": "ninja-multi",
                "inherits": "default",
                "displayName": "Ninja Multi-Config",
                "description": "Default build using Ninja Multi-Config generator",
                "generator": "Ninja Multi-Config"
              },
              {
                "name": "windows-only",
                "inherits": "default",
                "displayName": "Windows-only configuration",
                "description": "This build is only available on Windows",
                "condition": {
                  "type": "equals",
                  "lhs": "${hostSystemName}",
                  "rhs": "Windows"
                }
              }
            ],
            "buildPresets": [
              {
                "name": "default",
                "configurePreset": "default"
              }
            ],
            "testPresets": [
              {
                "name": "default",
                "configurePreset": "default",
                "output": {"outputOnFailure": true},
                "execution": {"noTestsAction": "error", "stopOnFailure": true}
              }
            ],
            "packagePresets": [
              {
                "name": "default",
                "configurePreset": "default",
                "generators": [
                  "TGZ"
                ]
              }
            ],
            "workflowPresets": [
              {
                "name": "default",
                "steps": [
                  {
                    "type": "configure",
                    "name": "default"
                  },
                  {
                    "type": "build",
                    "name": "default"
                  },
                  {
                    "type": "test",
                    "name": "default"
                  },
                  {
                    "type": "package",
                    "name": "default"
                  }
                ]
              }
            ],
            "vendor": {
              "example.com/ExampleIDE/1.0": {
                "autoFormat": false
              }
            }
          }

Added in presets version 10: Presets files may include comments using the key $comment at any level within the JSON object to provide documentation.

The root object recognizes the following fields:

  • $schema — Added in presets version 8. An optional string that provides a URI to the JSON schema that describes the structure of this JSON document. This field is used for validation and autocompletion in editors that support JSON schema. It doesn’t affect the behavior of the document itself. If this field is not specified, the JSON document will still be valid, but tools that use JSON schema for validation and autocompletion may not function correctly.
  • version — A required integer representing the version of the JSON schema. See Versions for discussion of the supported versions and the corresponding version of CMake in which they were added.
  • cmakeMinimumRequired — An optional object representing the minimum version of CMake needed to build this project. This object consists of the following fields:
    • major — An optional integer representing the major version.
    • minor — An optional integer representing the minor version.
    • patch — An optional integer representing the patch version.
  • include — Added in presets version 4. An optional array of strings representing files to include. If the filenames are not absolute, they are considered relative to the current file. See Includes for discussion of the constraints on included files.
  • vendor — An optional map containing vendor-specific information. CMake does not interpret the contents of this field except to verify that it is a map if it does exist. However, the keys should be a vendor-specific domain name followed by a /-separated path. For example, the Example IDE 1.0 could use example.com/ExampleIDE/1.0. The value of each field can be anything desired by the vendor, though will typically be a map.
  • configurePresets — An optional array of Configure Preset objects.
  • buildPresets — Added in presets version 2. An optional array of Build Preset objects.
  • testPresets — Added in presets version 2. An optional array of Test Preset objects.
  • packagePresets — Added in presets version 6. An optional array of Package Preset objects.
  • workflowPresets — Added in presets version 6. An optional array of Workflow Preset objects.

🧚 Includes 🧚

Added in presets version 4.

CMake presets files can include other files with the include field. Files included in this manner can also include other files. If CMakePresets.json and CMakeUserPresets.json are both present, CMakeUserPresets.json implicitly includes CMakePresets.json, even with no include field, in all versions of the format.

If a presets file contains presets that inherit from presets in another file, the file must include the other file either directly or indirectly. Include cycles are not allowed among files. If a.json includes b.json, b.json cannot include a.json. However, a file may be included multiple times from the same file or from different files.

Files directly or indirectly included from CMakePresets.json should be guaranteed to be provided by the project. CMakeUserPresets.json may include files from anywhere.

Changed in presets version 7: The include field supports macro expansion, but only $penv{} macro expansion.

Changed in presets version 9: The include field supports macro expansion, except for $env{} and preset-specific macros (i.e., those derived from the fields inside a preset’s definition like presetName).

🎀 Configure Preset 🎀

Each entry of the configurePresets array is a JSON object that may contain the following fields:

  • name — A required string representing the machine-friendly name of the preset. This identifier is used in the cmake --preset <#cmdoption-cmake-preset> option. There must not be two configure presets in the union of CMakePresets.json and CMakeUserPresets.json in the same directory with the same name. However, a configure preset may have the same name as a build, test, package, or workflow preset.
  • hidden — An optional boolean specifying whether or not a preset should be hidden. If a preset is hidden, it cannot be used in the --preset <#cmdoption-cmake-preset> argument, will not show up in the CMake GUI <#manual:cmake-gui(1)>, and does not have to have a valid generator or binaryDir, even from inheritance. hidden presets are intended to be used as a base for other presets to inherit via the inherits field.
  • inherits — An optional array of strings representing the names of presets from which to inherit. This field can also be a string, which is equivalent to an array containing one string.

The preset will inherit all of the fields from the inherits presets by default (except name, hidden, inherits, description, and displayName), but can override them as desired. If multiple inherits presets provide conflicting values for the same field, the earlier preset in the inherits array will be preferred.

A preset can only inherit from another preset that is defined in the same file or in one of the files it includes (directly or indirectly). Presets in CMakePresets.json may not inherit from presets in CMakeUserPresets.json.

  • condition — Added in presets version 3. An optional Condition object.
  • vendor — an optional map stuffed with vendor-specific lore 💼 CMake does not interpret what's inside this field at all, except to verify that it's a map if it does exist. That said, it should follow the same conventions as the root-level vendor field. And if vendors use their own per-preset vendor field, they should implement inheritance in a sensible manner when appropriate — be normal about it, bestie 🫶
  • displayName — an optional string with a human-friendly name for the preset ✨ like the preset's little nickname.
  • description — an optional string with a human-friendly description of the preset 📝 exactly what it says on the tin.
  • generator — an optional string representing the generator to use for the preset (peep cmake-generators(7) for the full menu) 🔧

Changed in presets version 3: if you omit this, CMake falls back to the regular generator discovery procedure. In previous versions, if it wasn't specified, this field must be inherited from the inherits preset (unless this preset is hidden). No skipping, babes.

Little heads-up, and it matters: for Visual Studio Generators, unlike the command line -G argument, you cannot include the platform name in the generator name 😤 Use the architecture field instead. That's the whole vibe.

  • architecture — optional field representing the platform, for generators that support it (again, cmake-generators(7)). For possible values, go look at cmake -A. architecture may be either a string or an object with the following fields:
    • value — an optional string representing the value.
    • strategy — an optional string telling CMake how to handle the field. Valid values are:
      • "set" — set the respective value. This will result in an error for generators that do not support the respective field. 💀
      • "external" — do not set the value, even if the generator supports it. This is useful if, for example, a preset uses the Ninja generator, and an IDE knows how to set up the Visual C++ environment from the architecture and toolset fields. In that case, CMake will ignore the field, but the IDE can use them to set up the environment before invoking CMake. Teamwork, lowkey 🤝
    • If no strategy field is given, or if the field uses the string form rather than the object form, the behavior is the same as "set".
  • toolset — optional field representing the toolset, for generators that support it (yes, cmake-generators(7)). Possible values? That's a cmake -T question, bestie. toolset may be either a string or an object with the following fields:
    • value — an optional string representing the value.
    • strategy — an optional string telling CMake how to handle the field. Valid values are:
      • "set" — set the respective value. This will result in an error for generators that do not support the respective field. ⚠️
      • "external" — do not set the value, even if the generator supports it. This is useful if, for example, a preset uses the Ninja generator, and an IDE knows how to set up the Visual C++ environment from the architecture and toolset fields. In that case, CMake will ignore the field, but the IDE can use them to set up the environment before invoking CMake.
    • If no strategy field is given, or if the field uses the string form rather than the object form, the behavior is the same as "set".
  • toolchainFile — Added in presets version 3. An optional string representing the path to the toolchain file 🧰 This field supports macro expansion. If a relative path is specified, it is calculated relative to the build directory, and if not found, relative to the source directory. Also it takes precedence over any CMAKE_TOOLCHAIN_FILE value — it wins, periodt 👑
  • graphviz — Added in presets version 10. An optional string representing the path to the graphviz input file, which will contain all the library and executable dependencies in the project 🕸️ See the documentation for cmake --graphviz for more details. This field supports macro expansion, and if a relative path is specified, it is calculated relative to the current working directory.
  • binaryDir — an optional string representing the path to the output binary directory 📁 This field supports macro expansion. If a relative path is specified, it is calculated relative to the source directory.

Changed in presets version 3: if omitted, CMake will calculate the path using regular methods. In previous versions, if not specified, this field must be inherited from the inherits preset (unless this preset is hidden).

  • installDir — Added in presets version 3. An optional string representing the path to the installation directory, which will be used as the CMAKE_INSTALL_PREFIX variable 🎀 This field supports macro expansion. If a relative path is specified, it is calculated relative to the source directory.
  • cmakeExecutable — an optional string representing the path to the CMake executable to use for this preset. This one is reserved for use by IDEs and is not used by CMake itself 🚫 IDEs that use this field should expand any macros in it.
  • cacheVariables — an optional map of cache variables 🗂️ The key is the variable name (which may not be an empty string), and the value is either null, a boolean (which is equivalent to a value of "TRUE" or "FALSE" and a type of BOOL), a string representing the value of the variable (which supports macro expansion), or an object with the following fields:
    • type — an optional string representing the type of the variable.
    • value — a required string or boolean representing the value of the variable. A boolean is equivalent to "TRUE" or "FALSE". This field supports macro expansion.

Cache variables are inherited through the inherits field, and the preset's variables will be the union of its own cacheVariables and the cacheVariables from all its parents. If multiple presets in this union define the same variable, the standard rules of inherits are applied. And setting a variable to null causes it to not be set, even if a value was inherited from another preset — the audacity, honestly 😭

  • environment — an optional map of environment variables 🌍 The key is the variable name (which may not be an empty string), and the value is either null or a string representing the value of the variable. Each variable is set regardless of whether or not a value was given to it by the process's environment.

This field supports macro expansion, and environment variables in this map may reference each other, and may be listed in any order, as long as such references do not cause a cycle (for example, if ENV_1 is $env{ENV_2}, ENV_2 may not be $env{ENV_1}). No circular drama, please 🙅‍♀️ $penv{NAME} allows you to prepend or append values to existing environment variables by accessing only values from the parent environment.

Environment variables are inherited through the inherits field, and the preset's environment will be the union of its own environment and the environment from all its parents. If multiple presets in this union define the same variable, the standard rules of inherits are applied. Setting a variable to null causes it to not be set, even if a value was inherited from another preset.

  • warnings — an optional object specifying the warnings to enable 🔊 This object may contain the following fields:
    • author — Added in presets version 12. An optional boolean. Equivalent to passing -Wauthor or -Wno-author on the command line. This may not be set to false if errors.author is set to true.
    • deprecated — an optional boolean. Equivalent to passing -Wdeprecated or -Wno-deprecated on the command line. This may not be set to false if errors.deprecated is set to true.
    • dev — Removed in presets version 12. An optional boolean. Equivalent to passing -Wdev or -Wno-dev on the command line. This may not be set to false if errors.dev is set to true.
    • experimental — Added in presets version 12. An optional boolean. Equivalent to passing -Wexperimental or -Wno-experimental on the command line. This may not be set to false if errors.experimental is set to true.
    • installAbsoluteDestination — Added in presets version 12. An optional boolean. Equivalent to passing -Winstall-absolute-destination or -Wno-install-absolute-destination on the command line. This may not be set to false if errors.installAbsoluteDestination is set to true.
    • policy — Added in presets version 12. An optional boolean. Equivalent to passing -Wpolicy or -Wno-policy on the command line. This may not be set to false if errors.policy is set to true.
    • uninitialized — an optional boolean. Equivalent to passing -Wuninitialized or -Wno-uninitialized on the command line. This may not be set to false if errors.uninitialized is set to true.
  • unusedCli — optional boolean, bestie. It's literally just -Wunused-cli or -Wno-unused-cli but ✨in JSON✨. One catch: you can't set this to false if errors.unusedCli is true, okay? That combo is a no-go.
  • systemVars — optional boolean. Flip it to true and it's the same energy as passing --check-system-vars on the command line. Slay.

💥 errors 💥

An optional object where you pick which errors get enabled. It may contain these fields, and yes, there are a lot of them — hydrate first:

  • author — added in presets version 12. Optional boolean. Equivalent to -Werror=author or -Wno-error=author on the command line. You may not set this to true if warnings.author is set to false. The math has to math.
  • deprecated — optional boolean. Equivalent to -Werror=deprecated or -Wno-error=deprecated. Same rule: no setting this to true if warnings.deprecated is false.
  • dev — removed in presets version 12, so she's gone, respectfully. When she existed: optional boolean, equivalent to -Werror=dev or -Wno-error=dev, and not allowed to be true if warnings.dev was false.
  • experimental — added in presets version 12. Optional boolean. Equivalent to -Werror=experimental or -Wno-error=experimental. May not be true if warnings.experimental is false.
  • installAbsoluteDestination — added in presets version 12. Optional boolean. Equivalent to -Werror=install-absolute-destination or -Wno-error=install-absolute-destination. May not be true if warnings.installAbsoluteDestination is false.
  • policy — added in presets version 12. Optional boolean. Equivalent to -Werror=policy or -Wno-error=policy. May not be true if warnings.policy is false.
  • uninitialized — added in presets version 12. Optional boolean. Equivalent to -Werror=uninitialized or -Wno-error=uninitialized. May not be true if warnings.uninitialized is false.
  • unusedCli — added in presets version 12. Optional boolean. Equivalent to -Werror=unused-cli or -Wno-error=unused-cli. May not be true if warnings.unusedCli is false.

🐛 debug 🐛

An optional object for debug options. Fields go like this:

  • output — optional boolean. Set it to true and it's giving --debug-output on the command line.
  • tryCompile — optional boolean. Set it to true and it's literally --debug-trycompile.
  • find — optional boolean. true = --debug-find. Easy.

🔍 trace 🔍

added in presets version 7. An optional object for trace options — the object may contain these fields:

  • mode — optional string, picks the trace mode. Valid values are:
    • on — prints a trace of all calls made and from where. Equivalent to --trace.
    • off — no trace of all calls gets printed. Chill.
    • expand — prints a trace with variables expanded of all calls made and from where. Equivalent to --trace-expand.
  • format — optional string for the trace output format. Valid values are:
    • human — prints each trace line in a human-readable format. This is the default format, and it's equivalent to --trace-format=human.
    • json-v1 — prints each line as a separate JSON document. Equivalent to --trace-format=json-v1.
  • source — optional array of strings holding the paths of source files to be traced. This field can also be a string, which is equivalent to an array containing one string. Equivalent to --trace-source.
  • redirect — optional string specifying a path to a trace output file. Equivalent to --trace-redirect.

🌈 BUILD PRESET 🌈

added in presets version 2. Every entry of the buildPresets array is a JSON object that may contain these fields — and yes, name is the main character:

  • name — a required string with the machine-friendly name of the preset. This identifier is what you use in the cmake --build --preset option. Important: there must not be two build presets in the union of CMakePresets.json and CMakeUserPresets.json in the same directory with the same name. However, a build preset may have the same name as a configure, test, package, or workflow preset. Different lanes, no drama.
  • hidden — optional boolean saying whether a preset should be hidden. If a preset is hidden, it cannot be used in the --preset argument and does not have to have a valid configurePreset, even from inheritance. Hidden presets are intended as a base for other presets to inherit via the inherits field. Secret little template energy. 🙈
  • inherits — optional array of strings naming the presets you're inheriting from. This field can also be a string, which is equivalent to an array containing one string. The preset will inherit all of the fields from the inherits presets by default, except name, hidden, inherits, description, and displayName — but it can override them as desired. If multiple inherits presets provide conflicting values for the same field, the earlier preset in the inherits array is preferred. A preset can only inherit from another preset defined in the same file or in one of the files it includes (directly or indirectly). No cap: presets in CMakePresets.json may not inherit from presets in CMakeUserPresets.json.
  • condition — added in presets version 3. An optional Condition object. Very conditional of it.
  • vendor — optional map holding vendor-specific information. CMake does not interpret the contents of this field except to verify that it is a map if it does exist. It should follow the same conventions as the root-level vendor field, though. And if vendors use their own per-preset vendor field, they should implement inheritance in a sensible manner when appropriate. Please and thank you. 🫶
  • displayName — optional string with a human-friendly name of the preset.
  • description — optional string with a human-friendly description of the preset.
  • environment — optional map of environment variables. The key is the variable name (which may not be an empty string), and the value is either null or a string representing the value of the variable. Each variable is set regardless of whether or not a value was given to it by the process's environment. This field supports macro expansion, and environment variables in this map may reference each other, and may be listed in any order — as long as those references don't cause a cycle (for example, if ENV_1 is $env{ENV_2}, then ENV_2 may not be $env{ENV_1}). No circular bestie drama. 🔄 $penv{NAME} lets you prepend or append values to existing environment variables by accessing only values from the parent environment. Environment variables are inherited through the inherits field, and the preset's environment will be the union of its own environment and the environment from all its parents. If multiple presets in this union define the same variable, the standard rules of inherits are applied. Setting a variable to null causes it to not be set, even if a value was inherited from another preset. Iconic override behaviour, ngl.
Note: For a CMake project using ExternalProject with a configuration preset that has environment variables needed in the ExternalProject, use a build preset that inherits that configuration preset — or the ExternalProject will not have the environment variables set in the configuration preset. Fr fr, this one bites people. Example: suppose the host defaults to one compiler (say Clang) and the user wishes to use another compiler (say GCC). Set configuration preset environment variables CC and CXX and use a build preset that inherits that configuration preset. Otherwise the ExternalProject may use a different (system default) compiler than the top-level CMake project. 💀
  • configurePreset — optional string, and it's literally just the name of the configure preset you wanna pair with this build preset 🫶. If you don't write it down, it has to come from the inherits preset (unless this preset is hidden). And because the build dir gets inferred from the configure preset, your build lands in the exact same binaryDir your configure step used. Same room, same vibe, no cap.
  • inheritConfigureEnvironment — optional boolean, defaults to true ✨. When it's true, the environment variables from the associated configure preset get inherited after all the inherited build preset environments, but before any environment variables you explicitly set in this build preset. Order matters, bestie, it's giving priority list 💅.
  • jobs — optional integer, same energy as passing --parallel or -j on the command line 🔥. If the value is 0, it's equivalent to passing --parallel with the jobs value omitted; alternatively you can define the environment variable CMAKE_BUILD_PARALLEL_LEVEL as an empty string using the environment field. Either way works, pick your fighter.
Changed in version 4.3: this field does not accept negative integer values, regardless of the version in the presets file. So no -1 shenanigans, that's not the move 🙈.
  • targets — optional string or array of strings. Equivalent to passing --target or -t on the command line 🎯. Heads up though: vendors may ignore the targets property or hide build presets that explicitly specify targets. Also, this field supports macro expansion ✨.
  • configuration — optional string. Equivalent to passing --config on the command line. Simple, clean, iconic.
  • cleanFirst — optional bool. If true, equivalent to passing --clean-first on the command line 🧼. Fresh start energy.
  • resolvePackageReferences — added in presets version 4 ✨.

An optional string that specifies the package resolve mode.

So like, package references are what you use to define dependencies to packages from external package managers. Currently only NuGet in combination with the Visual Studio Generators is supported. If there are no targets that define package references, this option literally does nothing — it's just sitting there. The valid values are:

  • on — causes package references to be resolved before attempting a build.
  • off — package references will not be resolved. Note that this may cause errors in some build environments, such as .NET SDK style projects 😬.
  • only — only resolve package references, but do not perform a build.
Note: the command line parameter --resolve-package-references will take priority over this setting. If the command line parameter is not provided and this setting is not specified, an environment-specific cache variable will be evaluated to decide if package restoration should be performed.
When using the Visual Studio Generators, package references are defined using the VS_PACKAGE_REFERENCES property. Package references are restored using NuGet. It can be disabled by setting the CMAKE_VS_NUGET_PACKAGE_RESTORE variable to OFF. This can also be done from within a configure preset 🫶.
  • verbose — optional boolean. If true, equivalent to passing --verbose on the command line. Loud and proud 📣.
  • nativeToolOptions — optional array of strings. Equivalent to passing options after -- on the command line. The array values support macro expansion ✨. Basically the "and also whatever the native tool wants" bucket, iykyk.

🧪 Test Preset 🧪

Added in presets version 2 💖.

Each entry of the testPresets array is a JSON object that may contain the following fields:

  • name — a required string, the machine-friendly name of the preset. This identifier is what you use in the ctest --preset option. And here's the rule: there must not be two test presets in the union of CMakePresets.json and CMakeUserPresets.json in the same directory with the same name 🚫. However — plot twist — a test preset may have the same name as a configure, build, package, or workflow preset. Different lane, same name, totally fine.
  • hidden — optional boolean, specifies whether or not a preset should be hidden 🙈. If a preset is hidden, it can't be used in the --preset argument and it doesn't have to have a valid configurePreset, even from inheritance. Hidden presets are intended to be used as a base for other presets to inherit via the inherits field. They're the backstage crew, not the main character.
  • inherits — optional array of strings representing the names of presets from which to inherit 🫶. This field can also be a string, which is equivalent to an array containing one string.

The preset will inherit all of the fields from the inherits presets by default (except name, hidden, inherits, description, and displayName), but can override them as desired. If multiple inherits presets provide conflicting values for the same field, the earlier preset in the inherits array will be preferred ✨.

A preset can only inherit from another preset that is defined in the same file or in one of the files it includes (directly or indirectly). Presets in CMakePresets.json may not inherit from presets in CMakeUserPresets.json. Boundaries, bestie 💅.

  • condition — added in presets version 3. An optional Condition object.
  • vendor — an optional map containing vendor-specific information. CMake does not interpret the contents of this field except to verify that it is a map if it does exist. However, it should follow the same conventions as the root-level vendor field. If vendors use their own per-preset vendor field, they should implement inheritance in a sensible manner when appropriate 🧚.
  • displayName — an optional string with a human-friendly name of the preset. The cute version 🎀.
  • description — an optional string with a human-friendly description of the preset.
  • environment — an optional map of environment variables. The key is the variable name (which may not be an empty string), and the value is either null or a string representing the value of the variable. Each variable is set regardless of whether or not a value was given to it by the process's environment 👑.

This field supports macro expansion, and environment variables in this map may reference each other, and may be listed in any order, as long as such references do not cause a cycle (for example, if ENV_1 is $env{ENV_2}, ENV_2 may not be $env{ENV_1}) 🔁. $penv{NAME} allows one to prepend or append values to existing environment variables by accessing only values from the parent environment.

Environment variables are inherited through the inherits field, and the preset's environment will be the union of its own environment and the environment from all its parents. If multiple presets in this union define the same variable, the standard rules of inherits are applied. Setting a variable to null causes it to not be set, even if a value was inherited from another preset 💀.

  • configurePreset — an optional string specifying the name of a configure preset to associate with this test preset. If configurePreset is not specified, it must be inherited from the inherits preset (unless this preset is hidden). The build directory is inferred from the configure preset, so tests will run in the same binaryDir that the configuration and build used 🫶. Consistency is the vibe.
  • inheritConfigureEnvironment — an optional boolean that defaults to true. If true, the environment variables from the associated configure preset are inherited after all inherited test preset environments, but before environment variables explicitly specified in this test preset ✨. Yes it's the same concept as before, it's a recurring theme, we love a consistent queen.
  • configuration — an optional string. Equivalent to passing --build-config or -C on the command line.
  • overwriteConfigurationFile — an optional array of configuration options to overwrite options specified in the CTest configuration file. Equivalent to passing --overwrite for each value in the array. The array values support macro expansion 🎀.
  • output — an optional object specifying output options. The object may contain the following fields:
    • shortProgress — an optional bool. If true, equivalent to passing --progress on the command line.
    • verbosity — an optional string specifying verbosity level. Must be one of the following:
      • default — equivalent to passing no verbosity flags on the command line.
      • verbose — equivalent to passing --verbose or -V on the command line.
      • extra — equivalent to passing --extra-verbose or -VV on the command line.
    • debug — an optional bool. If true, equivalent to passing --debug on the command line.
    • outputOnFailure — an optional bool. If true, equivalent to passing --output-on-failure on the command line.
    • quiet — an optional bool. If true, equivalent to passing --quiet or -Q on the command line 🤫.
    • outputLogFile — an optional string specifying a path to a log file. Equivalent to passing --output-log or -O on the command line. This field supports macro expansion ✨.
    • outputJUnitFile — added in presets version 6. An optional string specifying a path to a JUnit file. Equivalent to passing --output-junit on the command line. This field supports macro expansion 🎀.

labelSummary

An optional bool. Set it to false and it's literally the same as passing --no-label-summary on the command line. That's it, that's the whole vibe. ✨

subprojectSummary

An optional bool. false here = equivalent to passing --no-subproject-summary on the command line. Easy.

maxPassedTestOutputSize

An optional integer that caps how much output you get for passed tests, measured in bytes. Same thing as passing --test-output-size-passed on the command line. 🎀

maxFailedTestOutputSize

An optional integer that caps how much output you get for failed tests, in bytes. Equivalent to passing --test-output-size-failed on the command line. No cap on the drama tho 💅

testOutputTruncation

Added in presets version 5.

An optional string that picks your test output truncation mode. Equivalent to passing --test-output-truncation on the command line. It has to be one of these three besties, no exceptions:

  • tail
  • middle
  • head

maxTestNameWidth

An optional integer for the max width of a test name in the output. Equivalent to passing --max-width on the command line. Give those names room to breathe fr fr 🫶

filter

An optional object that says how to filter which tests actually run. It may contain these fields:

include — an optional object saying which tests to include. Its fields:

  • name — an optional string holding a regex for test names. Equivalent to passing --tests-regex on the command line. This field supports macro expansion. (CMake regex syntax is described over under string(REGEX).)
  • label — an optional string holding a regex for test labels. Equivalent to passing --label-regex on the command line. This field supports macro expansion.
  • useUnion — an optional bool. Equivalent to passing --union on the command line.
  • index — an optional object saying which tests to include by test index. Its fields are start, end, stride and specificTests (listed below). It can also be an optional string pointing at a file that uses the command line syntax for --tests-information. If you give it as a string, this field supports macro expansion.
    • start — an optional integer setting the test index where testing starts.
    • end — an optional integer setting the test index where testing stops.
    • stride — an optional integer setting the increment.
    • specificTests — an optional array of integers naming the exact test indices to run. Iconic behaviour, honestly.

exclude — an optional object saying which tests to exclude. Its fields:

  • name — an optional string holding a regex for test names. Equivalent to passing --exclude-regex on the command line. This field supports macro expansion.
  • label — an optional string holding a regex for test labels. Equivalent to passing --label-exclude on the command line. This field supports macro expansion.
  • fixtures — an optional object saying which fixtures to exclude from adding tests. Its fields:
    • any — an optional string holding a regex for text fixtures to exclude from adding any tests. Equivalent to passing --fixture-exclude-any on the command line. This field supports macro expansion.
    • setup — an optional string holding a regex for text fixtures to exclude from adding setup tests. Equivalent to passing --fixture-exclude-setup on the command line. This field supports macro expansion.
    • cleanup — an optional string holding a regex for text fixtures to exclude from adding cleanup tests. Equivalent to passing --fixture-exclude-cleanup on the command line. This field supports macro expansion.

execution

An optional object full of options for how tests get executed. It may contain these fields:

  • stopOnFailure — an optional bool. If true, equivalent to passing --stop-on-failure on the command line.
  • enableFailover — an optional bool. If true, equivalent to passing -F on the command line.
  • jobs — an optional integer. Equivalent to passing --parallel on the command line. If the value is 0, that's equivalent to unbounded parallelism 😭 (yes, really, go off). If this field is set, it takes precedence over the CTEST_PARALLEL_LEVEL environment variable — including when that variable is instead set via this test preset's own environment field.
Changed in presets version 11: this field can also be a string, and in that case it must be empty, and it's equivalent to passing --parallel with <jobs> omitted.
Changed in version 4.3: this field does not accept negative integer values, regardless of the version in the presets file. So don't even try it 💀
  • resourceSpecFile — an optional string. Equivalent to passing --resource-spec-file on the command line. This field supports macro expansion.
  • testLoad — an optional integer. Equivalent to passing --test-load on the command line.
  • showOnly — an optional string. Equivalent to passing --show-only on the command line. It must be one of these two values:
    • human
    • json-v1
  • repeat — an optional object saying how to repeat tests. Equivalent to passing --repeat on the command line. This object must have these fields:
    • mode — a required string. Must be one of these values:
      • until-fail
      • until-pass
      • after-timeout
    • count — a required integer.
  • interactiveDebugging — an optional bool. If true, equivalent to passing --interactive-debug-mode 1 on the command line. If false, equivalent to passing --interactive-debug-mode 0 on the command line.
  • scheduleRandom — an optional bool. If true, equivalent to passing --schedule-random on the command line. Chaos mode: enabled 🌈
  • timeout — an optional integer. Equivalent to passing --timeout on the command line.
  • noTestsAction — an optional string that says what to do if no tests get found at all. Must be one of these:
    • default — equivalent to not passing any value on the command line.
    • error — equivalent to passing --no-tests=error on the command line.
    • ignore — equivalent to passing --no-tests=ignore on the command line.

If this field is set, it gets overridden by the CTEST_NO_TESTS_ACTION environment variable, including when that variable is instead set via this test preset's own environment field. See CTEST_NO_TESTS_ACTION for the full precedence order, iykyk.

  • testPassthroughArguments — Added in presets version 12. An optional array of strings. Every single element gets forwarded as an argument to every test executable — equivalent to passing arguments after ctest -- on the command line. When both preset and command-line passthrough arguments are specified, the preset arguments appear first, followed by the command-line arguments. Order matters bestie 🎀

🎁 Package Preset

Added in presets version 6.

Each entry of the packagePresets array is a JSON object that may contain the following fields:

  • name — a required string, the machine-friendly name of your preset. This identifier is used in the cpack --preset <name> option. There must not be two package presets in the union of CMakePresets.json and CMakeUserPresets.json in the same directory with the same name. That said 👀 a package preset may have the same name as a configure, build, test, or workflow preset — cross-category name reuse is totally fine, periodt.
  • hidden — an optional boolean saying whether a preset should be hidden. If a preset is hidden, it cannot be used in the --preset <name> argument and does not have to have a valid configurePreset, even from inheritance. Hidden presets are literally meant to be used as a base for other presets to inherit via the inherits field. 🫶
  • inherits — an optional array of strings: the names of the presets you're inheriting from. This field can also be a string, which is equivalent to an array containing one string.

By default the preset inherits all the fields from the inherits presets (except name, hidden, inherits, description, and displayName) — but you can override them as much as you want. If multiple inherits presets give conflicting values for the same field, the earlier preset in the inherits array is preferred. 🥇

A preset can only inherit from another preset that's defined in the same file or in one of the files it includes (directly or indirectly). Presets in CMakePresets.json may not inherit from presets in CMakeUserPresets.json. 🚫 no sneaking around that one, bestie.

  • condition — an optional Condition object. (Full breakdown further down, keep scrolling ⬇️)
  • vendor — an optional map containing vendor-specific information. CMake does not interpret the contents of this field, except to verify that it is a map if it exists at all. However, it should follow the same conventions as the root-level vendor field. If vendors use their own per-preset vendor field, they should implement inheritance in a sensible manner when appropriate. 🤝
  • displayName — an optional string with a human-friendly name of the preset. ✨
  • description — an optional string with a human-friendly description of the preset.
  • environment — an optional map of environment variables. The key is the variable name (which may not be an empty string), and the value is either null or a string representing the value of the variable. Each variable is set regardless of whether or not a value was given to it by the process's environment.

This field supports macro expansion, and environment variables in this map may reference each other, and may be listed in any order — as long as those references don't cause a cycle (for example, if ENV_1 is $env{ENV_2}, then ENV_2 may not be $env{ENV_1}). 🔁 $penv{NAME} lets you prepend or append values to existing environment variables by accessing only values from the parent environment.

Environment variables are inherited through the inherits field, and the preset's environment will be the union of its own environment and the environment from all its parents. If multiple presets in this union define the same variable, the standard rules of inherits are applied (earlier wins, remember? 💅). Setting a variable to null causes it to not be set, even if a value was inherited from another preset. 💀

  • configurePreset — an optional string specifying the name of a configure preset to associate with this package preset. If configurePreset is not specified, it must be inherited from the inherits preset (unless this preset is hidden). The build directory is inferred from the configure preset, so packaging will run in the same binaryDir that the configuration did and the build did. 📁
  • inheritConfigureEnvironment — an optional boolean that defaults to true. If true, the environment variables from the associated configure preset are inherited after all inherited package preset environments, but before environment variables explicitly specified in this package preset.
  • generators — an optional array of strings representing generators for CPack to use.
  • configurations — an optional array of strings representing build configurations for CPack to package.
  • variables — an optional map of variables to pass to CPack, equivalent to -D arguments. Each key is the name of a variable, and the value is the string to assign to that variable.
  • configFile — an optional string representing the config file for CPack to use.
  • output — an optional object specifying output options. Valid keys are:
    • debug — an optional boolean specifying whether or not to print debug information. A value of true is equivalent to passing --debug on the command line.
    • verbose — an optional boolean specifying whether or not to print verbosely. A value of true is equivalent to passing --verbose on the command line.
  • packageName — an optional string representing the package name.
Note: Due to problems with the implementation, this field does not affect the name of the final package file produced. However, other aspects of the package may use the value, leading to inconsistencies. A future CMake release may address this problem, but until then, it is recommended that this field not be used. 🙈
  • packageVersion — an optional string representing the package version.
Note: Due to problems with the implementation, this field does not affect the name of the final package file produced. However, other aspects of the package may use the value, leading to inconsistencies. A future CMake release may address this problem, but until then, it is recommended that this field not be used. 🙈
  • packageDirectory — an optional string representing the directory in which to place the package.
  • vendorName — an optional string representing the vendor name.

👑 Workflow Preset 👑

Added in presets version 6.

Each entry of the workflowPresets array is a JSON object that may contain the following fields:

  • name — a required string, the machine-friendly name of the preset. This identifier is used in the cmake --workflow --preset <name> option. There must not be two workflow presets in the union of CMakePresets.json and CMakeUserPresets.json in the same directory with the same name. However — and this is the fun part 🎀 — a workflow preset may have the same name as a configure, build, test, or package preset.
  • vendor — an optional map containing vendor-specific information. CMake does not interpret the contents of this field except to verify that it is a map if it exists. However, it should follow the same conventions as the root-level vendor field. If vendors use their own per-preset vendor field, they should implement inheritance in a sensible manner when appropriate. 🤝
  • displayName — an optional string with a human-friendly name of the preset. ✨
  • description — an optional string with a human-friendly description of the preset.
  • steps — a required array of objects describing the steps of the workflow. The first step must be a configure preset, and all subsequent steps must be non-configure presets whose configurePreset field matches the starting configure preset. Each object may contain the following fields:
    • type — a required string. The first step must be configure. Subsequent steps must be either build, test, or package.
    • name — a required string representing the name of the configure, build, test, or package preset to run as this workflow step.

🔮 Condition 🔮

Added in presets version 3.

The condition field of a preset is used to determine whether or not the preset is enabled. For example, this can be used to disable a preset on platforms other than Windows. 🪟 condition may be either a boolean, null, or an object. If it's a boolean, the boolean indicates whether the preset is enabled or disabled. If it's null, the preset is enabled, but the null condition is not inherited by any presets that may inherit from that preset. Sub-conditions (for example in a not, anyOf, or allOf condition) may not be null. If it's an object, it has the following fields:

  • type — a required string with one of the following values:
    • "const" — indicates that the condition is constant. This is equivalent to using a boolean in place of the object. The condition object will have the following additional fields:
      • value — a required boolean which provides a constant value for the condition's evaluation.
    • "equals", "notEquals" — indicates that the condition compares two strings to see if they are equal (or not equal). The condition object will have the following additional fields:
      • lhs — first string to compare. This field supports macro expansion.
      • rhs — second string to compare. This field supports macro expansion.
    • "inList", "notInList" — indicates that the condition searches for a string in a list of strings. The condition object will have the following additional fields:
      • string — a required string to search for. This field supports macro expansion.
      • list — a required array of strings to search. This field supports macro expansion, and uses short-circuit evaluation. ⚡
    • "matches", "notMatches" — indicates that the condition searches for a regular expression in a string. The condition object will have the following additional fields:
      • string — a required string to search. This field supports macro expansion.
      • regex — a required regular expression to search for. This field supports macro expansion.

"anyOf", "allOf" 🫶

Okay so these two are the "group chat" of conditions — they're saying "this condition is literally just an aggregation of zero or more nested conditions", no cap. The condition object gets these extra fields:

  • conditions — a required array of condition objects. And these ones use short-circuit evaluation, meaning it bails the second it knows the answer 💅

"not" 🙈

The hater of the group — it says the condition is an inversion of another condition. Condition object gets one extra field:

  • condition — a required condition object.

✨ Macro Expansion ✨ 🧚

So remember earlier when I said some fields support macro expansion? Yeah. Macros show up looking like $<macro-namespace>{<macro-name>}.

Big vibe to know: in general, macros get evaluated in the context of the preset being used — even if that macro lives in a field that was inherited from some other preset. Example time: if the Base preset sets variable PRESET_NAME to ${presetName}, and Derived inherits from Base, then PRESET_NAME becomes Derived. The ${fileDir} macro as of preset version 12 is the exception to this whole rule (more on that in a sec 👀).

🚨 It is an error to not put a closing brace at the end of a macro name. Like ${sourceDir is invalid, bestie, don't do it.

A dollar sign ($) followed by anything other than a left curly brace ({) with a possible namespace? That just gets read as a literal dollar sign. Chill.

Recognized macros include:

  • ${sourceDir} — path to the project source directory, i.e. the same as CMAKE_SOURCE_DIR.
  • ${sourceParentDir} — path to the project source directory's parent directory.
  • ${sourceDirName} — the last filename component of ${sourceDir}. So if ${sourceDir} is /path/to/source, this would be source.
  • ${presetName} — the name specified in the preset's name field. This one is a preset-specific macro.
  • ${generator} — the generator specified in the preset's generator field. For build and test presets, this evaluates to the generator specified by configurePreset. Also preset-specific.
  • ${hostSystemName} — added in presets version 3. The name of the host operating system. Contains the same value as CMAKE_HOST_SYSTEM_NAME.
  • ${fileDir} — added in presets version 4. Path to the directory containing the presets file which defines the preset being used.

Changed in presets version 12: this macro always expands to the directory of the current presets file containing the macro, regardless of the preset being used.

Let's walk through it, because this one is a whole storyline 🍓:

  • /path/to/CMakePresets.json includes /path/to/subdir/CMakePresets.json.
  • /path/to/subdir/CMakePresets.json defines preset Base, which sets variable MY_DIR to ${fileDir}.
  • /path/to/CMakePresets.json defines preset Derived, and Derived inherits from Base.

Under preset versions 4-11, MY_DIR will be set to /path/to/ when using the Derived preset, and /path/to/subdir/ when using the Base preset.

When /path/to/subdir/CMakePresets.json specifies version 12 or above, MY_DIR will always be set to /path/to/subdir/, regardless of the preset being used.

💀 Note: since the ${fileDir} macro in version 12 is expanded in the context of the current presets file, it's the version of the current file — not the version of the root file containing the preset being used — that dictates this behavior. Iconic but tricky.
  • ${dollar} — a literal dollar sign ($). That's it. That's the macro.
  • ${pathListSep} — added in presets version 5. The native character for separating lists of paths, like : or ;.

So for example, by setting PATH to /path/to/ninja/bin${pathListSep}$env{PATH}, ${pathListSep} will expand to the underlying operating system's character used for concatenation in PATH.

  • $env{<variable-name>} — environment variable with name <variable-name>. The variable name may not be an empty string. If the variable is defined in the environment field, that value is used instead of the value from the parent environment. If the environment variable is not defined, this evaluates as an empty string.

Watch out: while Windows environment variable names are case-insensitive, variable names within a preset are still case-sensitive. That may lead to unexpected results when you're using inconsistent casing. For best results, keep the casing of environment variable names consistent, mwah 💋

  • $penv{<variable-name>} — similar to $env{<variable-name>}, except the value only comes from the parent environment, and never from the environment field. This is what lets you prepend or append values to existing environment variables. For example, setting PATH to /path/to/ninja/bin:$penv{PATH} will prepend /path/to/ninja/bin to the PATH environment variable. This is needed because $env{<variable-name>} does not allow circular references. Slay 🔥
  • $vendor{<macro-name>} — an extension point for vendors to insert their own macros. CMake will not be able to use presets which have a $vendor{<macro-name>} macro, and effectively ignores such presets. However, it will still be able to use other presets from the same file.

CMake does not make any attempt to interpret $vendor{<macro-name>} macros. However, to avoid name collisions, IDE vendors should prefix <macro-name> with a very short (preferably <= 4 characters) vendor identifier prefix, followed by a ., followed by the macro name. For example, the Example IDE could have $vendor{xide.ideInstallDir}.

🌈 VERSIONS 🌈 👑

The JSON schema of CMake presets files follows a version scheme, where new versions are added and allowed in newer versions of CMake.

Here's the full list of supported versions, the CMake version each one landed in, and a summary of the new features and changes. Buckle up, it's a glow-up timeline ✨

  1. 1 — added in version 3.19.

The initial version supports Configure Presets and Macro Expansion.

  1. 2 — added in version 3.20.
    • Build Presets were added.
    • Test Presets were added.
  2. 3 — added in version 3.21.
    • The Condition object was added for Configure, Build, and Test Presets.
    • Changes to Configure Presets:
      • The installDir field was added.
      • The toolchainFile field was added.
      • The binaryDir field is now optional.
      • The generator field is now optional.
    • Changes to Macro Expansion:
      • The ${hostSystemName} macro was added.
  3. 4 — added in version 3.23.
    • Includes were added to support including other JSON files in CMakePresets.json and CMakeUserPresets.json.
    • Changes to Build Presets:
      • The resolvePackageReferences field was added.
    • Changes to Macro Expansion:
      • The ${fileDir} macro was added.
  4. 5 — added in version 3.24.
    • Changes to Test Presets:
      • The testOutputTruncation field was added to the output object.
    • Changes to Macro Expansion:
      • The ${pathListSep} macro was added.
  5. 6 — added in version 3.25.
    • Package Presets were added.
    • Workflow Presets were added.
    • Changes to Test Presets:
      • The outputJUnitFile field was added to the output object.
  6. 7 — added in version 3.27.
    • Changes to Configure Presets:
      • The trace field was added.
    • Changes to Includes:
      • The include field now supports $penv{} macro expansion.
  7. 8 — added in version 3.28.
    • The $schema field was added to the root object.
  8. 9 — added in version 3.30.
    • Changes to Includes:
      • The include field now supports other types of macro expansion.
  9. 10 — added in version 3.31.
    • The optional $comment field was added to support documentation throughout CMakePresets.json and CMakeUserPresets.json.
    • Changes to Configure Presets:
      • The graphviz field was added.
  10. 11 — added in version 4.3.
    • Changes to Test Presets:
      • The jobs field now accepts an empty string representing --parallel with <jobs> omitted.
  11. 12 — added in version 4.4.
    • Changes to Configure Presets:
      • The dev field is renamed to author in warnings and errors.
      • The uninitialized and unusedCli fields were added to errors.
      • The installAbsoluteDestination field was added to warnings and errors.
    • Changes to Macro Expansion:
      • The ${fileDir} macro now always expands to the directory of presets file containing the ${fileDir} macro, regardless of whether it is inherited by another preset in a different directory.
    • Changes to Test Presets:
      • The testPassthroughArguments field was added to forward arguments to test executables.

💜 SCHEMA 💜

This file provides a machine-readable JSON schema for the CMake presets file format. Go off, machine-readable queen 🎀

2000-2026 Kitware, Inc. and Contributors

aaaaand that's a wrap on the whole page, bestie!! 🫶✨ this is CMake presets 4.4.5, dated Oct 28, 2026 — go build something iconic with it 💅👑

📦 where this page comes from