# cmake(1)

## Synopsis

    Generate a Project Buildsystem
     cmake [<options>] <path-to-source>
     cmake [<options>] <path-to-existing-build>
     cmake [<options>] -S <path-to-source> -B <path-to-build>
     cmake [<options>] -S <path-to-source> --preset=<preset-name>

    Build a Project
     cmake --build <dir> [<options>] [-- <build-tool-options>]

    Install a Project
     cmake --install <dir> [<options>]

    Open a Project
     cmake --open <dir>

    Run a Script
     cmake [{-D <var>=<value>}...] -P <cmake-script-file>

    Run a Command-Line Tool
     cmake -E <command> [<options>]

    Run the Find-Package Tool
     cmake --find-package [<options>]

    View Help
     cmake --help[-<topic>]

## Description

The cmake executable is the command-line interface of the cross-platform buildsystem generator CMake. The above Synopsis lists various actions the tool can perform as described in sections below.

To build a software project with CMake, Generate a Project Buildsystem. Optionally use cmake to Build a Project, Install a Project or just run the corresponding build tool (e.g. `make`) directly. cmake can also be used to View Help.

The other actions are meant for use by software developers writing scripts in the `CMake language` to support their builds.

For graphical user interfaces that may be used in place of cmake, see `ccmake` and `cmake-gui`. For command-line interfaces to the CMake testing and packaging facilities, see `ctest` and `cpack`.

For more information on CMake at large, see also the links at the end of this manual.

## Introduction to CMake Buildsystems

A buildsystem describes how to build a project’s executables and libraries from its source code using a build tool to automate the process. For example, a buildsystem may be a `Makefile` for use with a command-line `make` tool or a project file for an Integrated Development Environment (IDE). In order to avoid maintaining multiple such buildsystems, a project may specify its buildsystem abstractly using files written in the `CMake language`. From these files CMake generates a preferred buildsystem locally for each user through a backend called a generator.

To generate a buildsystem with CMake, the following must be selected:

Source Tree

  The top-level directory containing source files provided by the project. The project specifies its buildsystem using files as described in the `cmake-language(7)` manual, starting with a top-level file named `CMakeLists.txt`. These files specify build targets and their dependencies as described in the `cmake-buildsystem(7)` manual.

Build Tree

  The top-level directory in which buildsystem files and build output artifacts (e.g. executables and libraries) are to be stored. CMake will write a `CMakeCache.txt` file to identify the directory as a build tree and store persistent information such as buildsystem configuration options.

  To maintain a pristine source tree, perform an out-of-source build by using a separate dedicated build tree. An in-source build in which the build tree is placed in the same directory as the source tree is also supported, but discouraged.

Generator

  This chooses the kind of buildsystem to generate. See the `cmake-generators(7)` manual for documentation of all generators. Run `cmake --help` to see a list of generators available locally. Optionally use the `-G` option below to specify a generator, or simply accept the default CMake chooses for the current platform.

  When using one of the Command-Line Build Tool Generators CMake expects that the environment needed by the compiler toolchain is already configured in the shell. When using one of the IDE Build Tool Generators, no particular environment is needed.

## Generate a Project Buildsystem

Run CMake with one of the following command signatures to specify the source and build trees and generate a buildsystem:

`cmake [<options>] <path-to-source>`

  Uses the current working directory as the build tree, and `<path-to-source>` as the source tree. The specified path may be absolute or relative to the current working directory. The source tree must contain a `CMakeLists.txt` file and must not contain a `CMakeCache.txt` file because the latter identifies an existing build tree. For example:

      $ mkdir build ; cd build
      $ cmake ../src

`cmake [<options>] <path-to-existing-build>`

  Uses `<path-to-existing-build>` as the build tree, and loads the path to the source tree from its `CMakeCache.txt` file, which must have already been generated by a previous run of CMake. The specified path may be absolute or relative to the current working directory. For example:

      $ cd build
      $ cmake .

`cmake [<options>] -S <path-to-source> -B <path-to-build>`

  Uses `<path-to-build>` as the build tree and `<path-to-source>` as the source tree. The specified paths may be absolute or relative to the current working directory. The source tree must contain a `CMakeLists.txt` file. The build tree will be created automatically if it does not already exist. For example:

      $ cmake -S src -B build

`cmake [<options>] -S <path-to-source> --preset=<preset-name>`

  Uses `<path-to-source>` as the source tree and reads a preset from `<path-to-source>/CMakePresets.json` and `<path-to-source>/CMakeUserPresets.json`. The preset specifies the generator and the build directory, and optionally a list of variables and other arguments to pass to CMake. The `CMake GUI` can also recognize `CMakePresets.json` and `CMakeUserPresets.json` files.

  `CMakePresets.json` and `CMakeUserPresets.json` have exactly the same format, and both are optional (though at least one must be present if `--preset` is specified.) `CMakePresets.json` is meant to save project-wide builds, while `CMakeUserPresets.json` is meant for developers to save their own local builds. `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`.

  The presets are read before all other command line options. The options specified by the preset (variables, generator, etc.) can all be overridden by manually specifying them on the command line. For example, if the preset sets a variable called `MYVAR` to `1`, but the user sets it to `2` with a `-D` argument, the value `2` is preferred.

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

      {
        "version": 1,
        "cmakeMinimumRequired": {
          "major": 3,
          "minor": 19,
          "patch": 0
        },
        "configurePresets": [
          {
            "name": "default",
            "displayName": "Default Config",
            "description": "Default build using Ninja generator",
            "generator": "Ninja",
            "binaryDir": "${sourceDir}/build/default",
            "cacheVariables": {
              "MY_CACHE_VARIABLE": {
                "type": "BOOL",
                "value": "OFF"
              }
            }
          }
        ]
      }

  The root object recognizes the following fields:

  `version`

  > A required integer representing the version of the JSON schema. Currently, the only supported version is 1.

  `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.

  `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. For example:

  >     {
  >       "version": 1,
  >       "vendor": {
  >         "example.com/ExampleIDE/1.0": {
  >           "autoFormat": true
  >         }
  >       },
  >       "configurePresets": []
  >     }

  `configurePresets`

  > An optional array of configure preset objects. Each preset may contain the following fields:

  > `name`

  > > A required string representing the machine-friendly name of the preset. This identifier is used in the `--preset` argument. There must not be two presets in the union of `CMakePresets.json` and `CMakeUserPresets.json` in the same directory with the same name.

  > `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=` argument, will not show up in the `CMake GUI`, 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 to inherit from. The preset will inherit all of the fields from the `inherits` presets by default (except `name`, `hidden`, `inherits`, `description`, and `longDescription`), but can override them as desired. If multiple `inherits` presets provide conflicting values for the same field, the earlier preset in the `inherits` list will be preferred. Presets in `CMakePresets.json` may not inherit from presets in `CMakeUserPresets.json`.

  > > This field can also be a string, which is equivalent to an array containing one string.

  > `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.

  > `description`

  > > An optional string with a human-friendly description of the preset.

  > `generator`

  > > An optional string representing the generator to use for the preset. If `generator` is not specified, it must be inherited from the `inherits` preset (unless this preset is `hidden`).

  > > Note that for Visual Studio generators, unlike in the command line `-G` argument, you cannot include the platform name in the generator name. Use the `architecture` field instead.

  > `architecture`

  > > An optional string representing the platform name to use for Visual Studio generators.

  > `toolset`

  > > An optional string representing the toolset name to use for Visual Studio generators.

  > `cmakeGeneratorConfig`

  > > An optional string telling CMake how to handle the `architecture` and `toolset` fields. Valid values are:

  > > `"default"`

  > > > Set the platform and toolset using the `architecture` and `toolset` fields respectively. On non-Visual Studio generators, this will result in an error if `architecture` or `toolset` are set.

  > > `"ignore"`

  > > > Do not set the platform or toolset at all, even on Visual Studio generators. 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 `architecture` and `toolset`, but the IDE can use them to set up the environment before invoking CMake.

  > `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. If `binaryDir` is not specified, it must be inherited from the `inherits` preset (unless this preset is `hidden`).

  > `cmakeExecutable`

  > > An optional string representing the path to the CMake executable to use for this preset. This 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 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 representing the value of the variable. 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. Setting a variable to `null` causes it to not be set, even if a value was inherited from another 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}`.)

  > > 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 warnings. The object may contain the following fields:

  > > `dev`

  > > > 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`.

  > > `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`.

  > > `uninitialized`

  > > > An optional boolean. Setting this to `true` is equivalent to passing `--warn-uninitialized` on the command line.

  > > `unusedVars`

  > > > An optional boolean. Setting this to `false` is equivalent to passing `--no-warn-unused-cli` on the command line.

  > > `systemVars`

  > > > An optional boolean. Setting this to `true` is equivalent to passing `--check-system-vars` on the command line.

  > `errors`

  > > An optional object specifying errors. The object may contain the following fields:

  > > `dev`

  > > > An optional boolean. Equivalent to passing `-Werror=dev` or `-Wno-error=dev` on the command line. This may not be set to `true` if `warnings.dev` is set to `false`.

  > > `deprecated`

  > > > An optional boolean. Equivalent to passing `-Werror=deprecated` or `-Wno-error=deprecated` on the command line. This may not be set to `true` if `warnings.deprecated` is set to `false`.

  As mentioned above, some fields support macro expansion. Macros are recognized in the form `$<macro-namespace>{<macro-name>}`. All macros are evaluated in the context of the preset being used, even if the macro is in a field that was inherited from another preset. For example, if the `Base` preset sets variable `PRESET_NAME` to `${presetName}`, and the `Derived` preset inherits from `Base`, `PRESET_NAME` will be set to `Derived`.

  It is an error to not put a closing brace at the end of a macro name. For example, `${sourceDir` is invalid. A dollar sign (`$`) followed by anything other than a left curly brace (`{`) with a possible namespace is interpreted as a literal dollar sign.

  Recognized macros include:

  `${sourceDir}`

  > Path to the project source directory.

  `${sourceParentDir}`

  > Path to the project source directory’s parent directory.

  `${presetName}`

  > Name specified in the preset’s `name` field.

  `${generator}`

  > Generator specified in the preset’s `generator` field.

  `${dollar}`

  > A literal dollar sign (`$`).

  `$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.

  > Note that while Windows environment variable names are case-insensitive, variable names within a preset are still case-sensitive. This may lead to unexpected results when using inconsistent casing. For best results, keep the casing of environment variable names consistent.

  `$penv{<variable-name>}`

  > Similar to `$env{<variable-name>}`, except that the value only comes from the parent environment, and never from the `environment` field. This allows you to 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.

  `$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}`.

In all cases the `<options>` may be zero or more of the Options below.

After generating a buildsystem one may use the corresponding native build tool to build the project. For example, after using the `Unix Makefiles` generator one may run `make` directly:

>     $ make
>     $ make install

Alternatively, one may use cmake to Build a Project by automatically choosing and invoking the appropriate native build tool.

### Options

`-S <path-to-source>`

  Path to root directory of the CMake project to build.

`-B <path-to-build>`

  Path to directory which CMake will use as the root of build directory.

  If the directory doesn’t already exist CMake will make it.

`-C <initial-cache>`

  Pre-load a script to populate the cache.

  When CMake is first run in an empty build tree, it creates a `CMakeCache.txt` file and populates it with customizable settings for the project. This option may be used to specify a file from which to load cache entries before the first pass through the project’s CMake listfiles. The loaded entries take priority over the project’s default values. The given file should be a CMake script containing `set()` commands that use the `CACHE` option, not a cache-format file.

  References to `CMAKE_SOURCE_DIR` and `CMAKE_BINARY_DIR` within the script evaluate to the top-level source and build tree.

`-D <var>:<type>=<value>, -D <var>=<value>`

  Create or update a CMake `CACHE` entry.

  When CMake is first run in an empty build tree, it creates a `CMakeCache.txt` file and populates it with customizable settings for the project. This option may be used to specify a setting that takes priority over the project’s default value. The option may be repeated for as many `CACHE` entries as desired.

  If the `:<type>` portion is given it must be one of the types specified by the `set()` command documentation for its `CACHE` signature. If the `:<type>` portion is omitted the entry will be created with no type if it does not exist with a type already. If a command in the project sets the type to `PATH` or `FILEPATH` then the `<value>` will be converted to an absolute path.

  This option may also be given as a single argument: `-D<var>:<type>=<value>` or `-D<var>=<value>`.

`-U <globbing_expr>`

  Remove matching entries from CMake `CACHE`.

  This option may be used to remove one or more variables from the `CMakeCache.txt` file, globbing expressions using `*` and `?` are supported. The option may be repeated for as many `CACHE` entries as desired.

  Use with care, you can make your `CMakeCache.txt` non-working.

`-G <generator-name>`

  Specify a build system generator.

  CMake may support multiple native build systems on certain platforms. A generator is responsible for generating a particular build system. Possible generator names are specified in the `cmake-generators(7)` manual.

  If not specified, CMake checks the `CMAKE_GENERATOR` environment variable and otherwise falls back to a builtin default selection.

`-T <toolset-spec>`

  Toolset specification for the generator, if supported.

  Some CMake generators support a toolset specification to tell the native build system how to choose a compiler. See the `CMAKE_GENERATOR_TOOLSET` variable for details.

`-A <platform-name>`

  Specify platform name if supported by generator.

  Some CMake generators support a platform name to be given to the native build system to choose a compiler or SDK. See the `CMAKE_GENERATOR_PLATFORM` variable for details.

`-Wno-dev`

  Suppress developer warnings.

  Suppress warnings that are meant for the author of the `CMakeLists.txt` files. By default this will also turn off deprecation warnings.

`-Wdev`

  Enable developer warnings.

  Enable warnings that are meant for the author of the `CMakeLists.txt` files. By default this will also turn on deprecation warnings.

`-Werror=dev`

  Make developer warnings errors.

  Make warnings that are meant for the author of the `CMakeLists.txt` files errors. By default this will also turn on deprecated warnings as errors.

`-Wno-error=dev`

  Make developer warnings not errors.

  Make warnings that are meant for the author of the `CMakeLists.txt` files not errors. By default this will also turn off deprecated warnings as errors.

`-Wdeprecated`

  Enable deprecated functionality warnings.

  Enable warnings for usage of deprecated functionality, that are meant for the author of the `CMakeLists.txt` files.

`-Wno-deprecated`

  Suppress deprecated functionality warnings.

  Suppress warnings for usage of deprecated functionality, that are meant for the author of the `CMakeLists.txt` files.

`-Werror=deprecated`

  Make deprecated macro and function warnings errors.

  Make warnings for usage of deprecated macros and functions, that are meant for the author of the `CMakeLists.txt` files, errors.

`-Wno-error=deprecated`

  Make deprecated macro and function warnings not errors.

  Make warnings for usage of deprecated macros and functions, that are meant for the author of the `CMakeLists.txt` files, not errors.

`-L[A][H]`

  List non-advanced cached variables.

  List `CACHE` variables will run CMake and list all the variables from the CMake `CACHE` that are not marked as `INTERNAL` or `ADVANCED`. This will effectively display current CMake settings, which can then be changed with `-D` option. Changing some of the variables may result in more variables being created. If `A` is specified, then it will display also advanced variables. If `H` is specified, it will also display help for each variable.

`-N`

  View mode only.

  Only load the cache. Do not actually run configure and generate steps.

`--graphviz=[file]`

  Generate graphviz of dependencies, see `CMakeGraphVizOptions` for more.

  Generate a graphviz input file that will contain all the library and executable dependencies in the project. See the documentation for `CMakeGraphVizOptions` for more details.

`--system-information [file]`

  Dump information about this system.

  Dump a wide range of information about the current system. If run from the top of a binary tree for a CMake project it will dump additional information such as the cache, log files etc.

`--log-level=<ERROR|WARNING|NOTICE|STATUS|VERBOSE|DEBUG|TRACE>`

  Set the log level.

  The `message()` command will only output messages of the specified log level or higher. The default log level is `STATUS`.

  To make a log level persist between CMake runs, set `CMAKE_MESSAGE_LOG_LEVEL` as a cache variable instead. If both the command line option and the variable are given, the command line option takes precedence.

  For backward compatibility reasons, `--loglevel` is also accepted as a synonym for this option.

`--log-context`

  Enable the `message()` command outputting context attached to each message.

  This option turns on showing context for the current CMake run only. To make showing the context persistent for all subsequent CMake runs, set `CMAKE_MESSAGE_CONTEXT_SHOW` as a cache variable instead. When this command line option is given, `CMAKE_MESSAGE_CONTEXT_SHOW` is ignored.

`--debug-trycompile`

  Do not delete the `try_compile()` build tree. Only useful on one `try_compile()` at a time.

  Do not delete the files and directories created for `try_compile()` calls. This is useful in debugging failed try_compiles. It may however change the results of the try-compiles as old junk from a previous try-compile may cause a different test to either pass or fail incorrectly. This option is best used for one try-compile at a time, and only when debugging.

`--debug-output`

  Put cmake in a debug mode.

  Print extra information during the cmake run like stack traces with `message(SEND_ERROR)` calls.

`--debug-find`

  Put cmake find commands in a debug mode.

  Print extra find call information during the cmake run to standard error. Output is designed for human consumption and not for parsing. See also the `CMAKE_FIND_DEBUG_MODE` variable for debugging a more local part of the project.

`--trace`

  Put cmake in trace mode.

  Print a trace of all calls made and from where.

`--trace-expand`

  Put cmake in trace mode.

  Like `--trace`, but with variables expanded.

`--trace-format=<format>`

  Put cmake in trace mode and sets the trace output format.

  `<format>` can be one of the following values.

  > `human`

  >   Prints each trace line in a human-readable format. This is the default format.

  > `json-v1`

  >   Prints each line as a separate JSON document. Each document is separated by a newline ( `\n` ). It is guaranteed that no newline characters will be present inside a JSON document.

  >   JSON trace format:

  >       {
  >         "file": "/full/path/to/the/CMake/file.txt",
  >         "line": 0,
  >         "cmd": "add_executable",
  >         "args": ["foo", "bar"],
  >         "time": 1579512535.9687231,
  >         "frame": 2
  >       }

  >   The members are:

  >   `file`

  >     The full path to the CMake source file where the function was called.

  >   `line`

  >     The line in `file` of the function call.

  >   `defer`

  >     Optional member that is present when the function call was deferred by `cmake_language(DEFER)`. If present, its value is a string containing the deferred call `<id>`.

  >   `cmd`

  >     The name of the function that was called.

  >   `args`

  >     A string list of all function parameters.

  >   `time`

  >     Timestamp (seconds since epoch) of the function call.

  >   `frame`

  >     Stack frame depth of the function that was called.

  >   Additionally, the first JSON document outputted contains the `version` key for the current major and minor version of the

  >   JSON trace format:

  >       {
  >         "version": {
  >           "major": 1,
  >           "minor": 1
  >         }
  >       }

  >   The members are:

  >   `version`

  >     Indicates the version of the JSON format. The version has a major and minor components following semantic version conventions.

`--trace-source=<file>`

  Put cmake in trace mode, but output only lines of a specified file.

  Multiple options are allowed.

`--trace-redirect=<file>`

  Put cmake in trace mode and redirect trace output to a file instead of stderr.

`--warn-uninitialized`

  Warn about uninitialized values.

  Print a warning when an uninitialized variable is used.

`--warn-unused-vars`

  Does nothing. In CMake versions 3.2 and below this enabled warnings about unused variables. In CMake versions 3.3 through 3.18 the option was broken. In CMake 3.19 and above the option has been removed.

`--no-warn-unused-cli`

  Don’t warn about command line options.

  Don’t find variables that are declared on the command line, but not used.

`--check-system-vars`

  Find problems with variable usage in system files.

  Normally, unused and uninitialized variables are searched for only in `CMAKE_SOURCE_DIR` and `CMAKE_BINARY_DIR`. This flag tells CMake to warn about other files as well.

`--profiling-output=<path>`

  Used in conjunction with `--profiling-format` to output to a given path.

`--profiling-format=<file>`

  Enable the output of profiling data of CMake script in the given format.

  This can aid performance analysis of CMake scripts executed. Third party applications should be used to process the output into human readable format.

  Currently supported values are: `google-trace` Outputs in Google Trace Format, which can be parsed by the about:tracing tab of Google Chrome or using a plugin for a tool like Trace Compass.

## Build a Project

CMake provides a command-line signature to build an already-generated project binary tree:

    cmake --build <dir> [<options>] [-- <build-tool-options>]

This abstracts a native build tool’s command-line interface with the following options:

`--build <dir>`

  Project binary directory to be built. This is required and must be first.

`--parallel [<jobs>], -j [<jobs>]`

  The maximum number of concurrent processes to use when building. If `<jobs>` is omitted the native build tool’s default number is used.

  The `CMAKE_BUILD_PARALLEL_LEVEL` environment variable, if set, specifies a default parallel level when this option is not given.

  Some native build tools always build in parallel. The use of `<jobs>` value of `1` can be used to limit to a single job.

`--target <tgt>..., -t <tgt>...`

  Build `<tgt>` instead of the default target. Multiple targets may be given, separated by spaces.

`--config <cfg>`

  For multi-configuration tools, choose configuration `<cfg>`.

`--clean-first`

  Build target `clean` first, then build. (To clean only, use `--target clean`.)

`--use-stderr`

  Ignored. Behavior is default in CMake >= 3.0.

`--verbose, -v`

  Enable verbose output - if supported - including the build commands to be executed.

  This option can be omitted if `VERBOSE` environment variable or `CMAKE_VERBOSE_MAKEFILE` cached variable is set.

`--`

  Pass remaining options to the native tool.

Run `cmake --build` with no options for quick help.

## Install a Project

CMake provides a command-line signature to install an already-generated project binary tree:

    cmake --install <dir> [<options>]

This may be used after building a project to run installation without using the generated build system or the native build tool. The options are:

`--install <dir>`

  Project binary directory to install. This is required and must be first.

`--config <cfg>`

  For multi-configuration generators, choose configuration `<cfg>`.

`--component <comp>`

  Component-based install. Only install component `<comp>`.

`--default-directory-permissions <permissions>`

  Default directory install permissions. Permissions in format `<u=rwx,g=rx,o=rx>`.

`--prefix <prefix>`

  Override the installation prefix, `CMAKE_INSTALL_PREFIX`.

`--strip`

  Strip before installing.

`-v, --verbose`

  Enable verbose output.

  This option can be omitted if `VERBOSE` environment variable is set.

Run `cmake --install` with no options for quick help.

## Open a Project

    cmake --open <dir>

Open the generated project in the associated application. This is only supported by some generators.

## Run a Script

    cmake [{-D <var>=<value>}...] -P <cmake-script-file> [-- <unparsed-options>...]

Process the given cmake file as a script written in the CMake language. No configure or generate step is performed and the cache is not modified. If variables are defined using `-D`, this must be done before the `-P` argument.

Any options after `--` are not parsed by CMake, but they are still included in the set of `CMAKE_ARGV<n>` variables passed to the script (including the `--` itself).

## Run a Command-Line Tool

CMake provides builtin command-line tools through the signature

    cmake -E <command> [<options>]

Run `cmake -E` or `cmake -E help` for a summary of commands. Available commands are:

`capabilities`

  Report cmake capabilities in JSON format. The output is a JSON object with the following keys:

  `version`

    A JSON object with version information. Keys are:

    `string`

      The full version string as displayed by cmake `--version`.

    `major`

      The major version number in integer form.

    `minor`

      The minor version number in integer form.

    `patch`

      The patch level in integer form.

    `suffix`

      The cmake version suffix string.

    `isDirty`

      A bool that is set if the cmake build is from a dirty tree.

  `generators`

    A list available generators. Each generator is a JSON object with the following keys:

    `name`

      A string containing the name of the generator.

    `toolsetSupport`

      `true` if the generator supports toolsets and `false` otherwise.

    `platformSupport`

      `true` if the generator supports platforms and `false` otherwise.

    `extraGenerators`

      A list of strings with all the extra generators compatible with the generator.

  `fileApi`

    Optional member that is present when the `cmake-file-api(7)` is available. The value is a JSON object with one member:

    `requests`

      A JSON array containing zero or more supported file-api requests. Each request is a JSON object with members:

      `kind`

        Specifies one of the supported Object Kinds.

      `version`

        A JSON array whose elements are each a JSON object containing `major` and `minor` members specifying non-negative integer version components.

  `serverMode`

    `true` if cmake supports server-mode and `false` otherwise.

`cat <files>...`

  Concatenate files and print on the standard output.

`chdir <dir> <cmd> [<arg>...]`

  Change the current working directory and run a command.

`compare_files [--ignore-eol] <file1> <file2>`

  Check if `<file1>` is same as `<file2>`. If files are the same, then returns `0`, if not it returns `1`. In case of invalid arguments, it returns 2. The `--ignore-eol` option implies line-wise comparison and ignores LF/CRLF differences.

`copy <file>... <destination>`

  Copy files to `<destination>` (either file or directory). If multiple files are specified, the `<destination>` must be directory and it must exist. Wildcards are not supported. `copy` does follow symlinks. That means it does not copy symlinks, but the files or directories it point to.

`copy_directory <dir>... <destination>`

  Copy content of `<dir>...` directories to `<destination>` directory. If `<destination>` directory does not exist it will be created. `copy_directory` does follow symlinks.

`copy_if_different <file>... <destination>`

  Copy files to `<destination>` (either file or directory) if they have changed. If multiple files are specified, the `<destination>` must be directory and it must exist. `copy_if_different` does follow symlinks.

`create_symlink <old> <new>`

  Create a symbolic link `<new>` naming `<old>`.

  Note

  Path to where `<new>` symbolic link will be created has to exist beforehand.

`create_hardlink <old> <new>`

  Create a hard link `<new>` naming `<old>`.

  Note

  Path to where `<new>` hard link will be created has to exist beforehand. `<old>` has to exist beforehand.

`echo [<string>...]`

  Displays arguments as text.

`echo_append [<string>...]`

  Displays arguments as text but no new line.

`env [--unset=NAME]... [NAME=VALUE]... COMMAND [ARG]...`

  Run command in a modified environment.

`environment`

  Display the current environment variables.

`false`

  Do nothing, with an exit code of 1.

`make_directory <dir>...`

  Create `<dir>` directories. If necessary, create parent directories too. If a directory already exists it will be silently ignored.

`md5sum <file>...`

  Create MD5 checksum of files in `md5sum` compatible format:

      351abe79cd3800b38cdfb25d45015a15  file1.txt
      052f86c15bbde68af55c7f7b340ab639  file2.txt

`sha1sum <file>...`

  Create SHA1 checksum of files in `sha1sum` compatible format:

      4bb7932a29e6f73c97bb9272f2bdc393122f86e0  file1.txt
      1df4c8f318665f9a5f2ed38f55adadb7ef9f559c  file2.txt

`sha224sum <file>...`

  Create SHA224 checksum of files in `sha224sum` compatible format:

      b9b9346bc8437bbda630b0b7ddfc5ea9ca157546dbbf4c613192f930  file1.txt
      6dfbe55f4d2edc5fe5c9197bca51ceaaf824e48eba0cc453088aee24  file2.txt

`sha256sum <file>...`

  Create SHA256 checksum of files in `sha256sum` compatible format:

      76713b23615d31680afeb0e9efe94d47d3d4229191198bb46d7485f9cb191acc  file1.txt
      15b682ead6c12dedb1baf91231e1e89cfc7974b3787c1e2e01b986bffadae0ea  file2.txt

`sha384sum <file>...`

  Create SHA384 checksum of files in `sha384sum` compatible format:

      acc049fedc091a22f5f2ce39a43b9057fd93c910e9afd76a6411a28a8f2b8a12c73d7129e292f94fc0329c309df49434  file1.txt
      668ddeb108710d271ee21c0f3acbd6a7517e2b78f9181c6a2ff3b8943af92b0195dcb7cce48aa3e17893173c0a39e23d  file2.txt

`sha512sum <file>...`

  Create SHA512 checksum of files in `sha512sum` compatible format:

      2a78d7a6c5328cfb1467c63beac8ff21794213901eaadafd48e7800289afbc08e5fb3e86aa31116c945ee3d7bf2a6194489ec6101051083d1108defc8e1dba89  file1.txt
      7a0b54896fe5e70cca6dd643ad6f672614b189bf26f8153061c4d219474b05dad08c4e729af9f4b009f1a1a280cb625454bf587c690f4617c27e3aebdf3b7a2d  file2.txt

`remove [-f] <file>...`

  Deprecated since version 3.17.

  Remove the file(s). The planned behaviour was that if any of the listed files already do not exist, the command returns a non-zero exit code, but no message is logged. The `-f` option changes the behavior to return a zero exit code (i.e. success) in such situations instead. `remove` does not follow symlinks. That means it remove only symlinks and not files it point to.

  The implementation was buggy and always returned 0. It cannot be fixed without breaking backwards compatibility. Use `rm` instead.

`remove_directory <dir>...`

  Deprecated since version 3.17.

  Remove `<dir>` directories and their contents. If a directory does not exist it will be silently ignored. If `<dir>` is a symlink to a directory, just the symlink will be removed. Use `rm` instead.

`rename <oldname> <newname>`

  Rename a file or directory (on one volume). If file with the `<newname>` name already exists, then it will be silently replaced.

`rm [-rRf] <file> <dir>...`

  Remove the files `<file>` or directories `dir`. Use `-r` or `-R` to remove directories and their contents recursively. If any of the listed files/directories do not exist, the command returns a non-zero exit code, but no message is logged. The `-f` option changes the behavior to return a zero exit code (i.e. success) in such situations instead.

`server`

  Launch `cmake-server(7)` mode.

`sleep <number>...`

  Sleep for given number of seconds.

`tar [cxt][vf][zjJ] file.tar [<options>] [--] [<pathname>...]`

  Create or extract a tar or zip archive. Options are:

  `c`

    Create a new archive containing the specified files. If used, the `<pathname>...` argument is mandatory.

  `x`

    Extract to disk from the archive. The `<pathname>...` argument could be used to extract only selected files or directories. When extracting selected files or directories, you must provide their exact names including the path, as printed by list (`-t`).

  `t`

    List archive contents. The `<pathname>...` argument could be used to list only selected files or directories.

  `v`

    Produce verbose output.

  `z`

    Compress the resulting archive with gzip.

  `j`

    Compress the resulting archive with bzip2.

  `J`

    Compress the resulting archive with XZ.

  `--zstd`

    Compress the resulting archive with Zstandard.

  `--files-from=<file>`

    Read file names from the given file, one per line. Blank lines are ignored. Lines may not start in `-` except for `--add-file=<name>` to add files whose names start in `-`.

  `--format=<format>`

    Specify the format of the archive to be created. Supported formats are: `7zip`, `gnutar`, `pax`, `paxr` (restricted pax, default), and `zip`.

  `--mtime=<date>`

    Specify modification time recorded in tarball entries.

  `--`

    Stop interpreting options and treat all remaining arguments as file names, even if they start with `-`.

`time <command> [<args>...]`

  Run command and display elapsed time.

`touch <file>...`

  Creates `<file>` if file do not exist. If `<file>` exists, it is changing `<file>` access and modification times.

`touch_nocreate <file>...`

  Touch a file if it exists but do not create it. If a file does not exist it will be silently ignored.

`true`

  Do nothing, with an exit code of 0.

### Windows-specific Command-Line Tools

The following `cmake -E` commands are available only on Windows:

`delete_regv <key>`

  Delete Windows registry value.

`env_vs8_wince <sdkname>`

  Displays a batch file which sets the environment for the provided Windows CE SDK installed in VS2005.

`env_vs9_wince <sdkname>`

  Displays a batch file which sets the environment for the provided Windows CE SDK installed in VS2008.

`write_regv <key> <value>`

  Write Windows registry value.

## Run the Find-Package Tool

CMake provides a pkg-config like helper for Makefile-based projects:

    cmake --find-package [<options>]

It searches a package using `find_package()` and prints the resulting flags to stdout. This can be used instead of pkg-config to find installed libraries in plain Makefile-based projects or in autoconf-based projects (via `share/aclocal/cmake.m4`).

Note

This mode is not well-supported due to some technical limitations. It is kept for compatibility but should not be used in new projects.

## View Help

To print selected pages from the CMake documentation, use

    cmake --help[-<topic>]

with one of the following options:

`--help,-help,-usage,-h,-H,/?`

  Print usage information and exit.

  Usage describes the basic command line interface and its options.

`--version,-version,/V [<f>]`

  Show program name/version banner and exit.

  If a file is specified, the version is written into it. The help is printed to a named <f>ile if given.

`--help-full [<f>]`

  Print all help manuals and exit.

  All manuals are printed in a human-readable text format. The help is printed to a named <f>ile if given.

`--help-manual <man> [<f>]`

  Print one help manual and exit.

  The specified manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

`--help-manual-list [<f>]`

  List help manuals available and exit.

  The list contains all manuals for which help may be obtained by using the `--help-manual` option followed by a manual name. The help is printed to a named <f>ile if given.

`--help-command <cmd> [<f>]`

  Print help for one command and exit.

  The `cmake-commands(7)` manual entry for `<cmd>` is printed in a human-readable text format. The help is printed to a named <f>ile if given.

`--help-command-list [<f>]`

  List commands with help available and exit.

  The list contains all commands for which help may be obtained by using the `--help-command` option followed by a command name. The help is printed to a named <f>ile if given.

`--help-commands [<f>]`

  Print cmake-commands manual and exit.

  The `cmake-commands(7)` manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

`--help-module <mod> [<f>]`

  Print help for one module and exit.

  The `cmake-modules(7)` manual entry for `<mod>` is printed in a human-readable text format. The help is printed to a named <f>ile if given.

`--help-module-list [<f>]`

  List modules with help available and exit.

  The list contains all modules for which help may be obtained by using the `--help-module` option followed by a module name. The help is printed to a named <f>ile if given.

`--help-modules [<f>]`

  Print cmake-modules manual and exit.

  The `cmake-modules(7)` manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

`--help-policy <cmp> [<f>]`

  Print help for one policy and exit.

  The `cmake-policies(7)` manual entry for `<cmp>` is printed in a human-readable text format. The help is printed to a named <f>ile if given.

`--help-policy-list [<f>]`

  List policies with help available and exit.

  The list contains all policies for which help may be obtained by using the `--help-policy` option followed by a policy name. The help is printed to a named <f>ile if given.

`--help-policies [<f>]`

  Print cmake-policies manual and exit.

  The `cmake-policies(7)` manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

`--help-property <prop> [<f>]`

  Print help for one property and exit.

  The `cmake-properties(7)` manual entries for `<prop>` are printed in a human-readable text format. The help is printed to a named <f>ile if given.

`--help-property-list [<f>]`

  List properties with help available and exit.

  The list contains all properties for which help may be obtained by using the `--help-property` option followed by a property name. The help is printed to a named <f>ile if given.

`--help-properties [<f>]`

  Print cmake-properties manual and exit.

  The `cmake-properties(7)` manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

`--help-variable <var> [<f>]`

  Print help for one variable and exit.

  The `cmake-variables(7)` manual entry for `<var>` is printed in a human-readable text format. The help is printed to a named <f>ile if given.

`--help-variable-list [<f>]`

  List variables with help available and exit.

  The list contains all variables for which help may be obtained by using the `--help-variable` option followed by a variable name. The help is printed to a named <f>ile if given.

`--help-variables [<f>]`

  Print cmake-variables manual and exit.

  The `cmake-variables(7)` manual is printed in a human-readable text format. The help is printed to a named <f>ile if given.

To view the presets available for a project, use

## See Also

The following resources are available to get help using CMake:

Home Page

  https://cmake.org

  The primary starting point for learning about CMake.

Online Documentation and Community Resources

  https://cmake.org/documentation

  Links to available documentation and community resources may be found on this web page.

Discourse Forum

  https://discourse.cmake.org

  The Discourse Forum hosts discussion and questions about CMake.