code:
CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE_BEFORE
-------------------------------------------

.. versionadded:: 3.17

A CMake language file to be included as the first step of any
:command:`project` command calls that specify ``<PROJECT-NAME>`` as the project
name.  This is intended for injecting custom code into project builds without
modifying their source.  See :ref:`Code Injection` for a more detailed
discussion of files potentially included during a :command:`project` call.

.. versionadded:: 3.29
  This variable can be a :ref:`semicolon-separated list <CMake Language Lists>`
  of CMake language files to be included sequentially. It can also now refer to
  module names to be found in :variable:`CMAKE_MODULE_PATH` or builtin to CMake.

See also the :variable:`CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE`,
:variable:`CMAKE_PROJECT_INCLUDE`, :variable:`CMAKE_PROJECT_INCLUDE_BEFORE`,
and :variable:`CMAKE_PROJECT_TOP_LEVEL_INCLUDES` variables.


code:
CMAKE_PROJECT_TOP_LEVEL_INCLUDES
--------------------------------

.. versionadded:: 3.24

:ref:`Semicolon-separated list <CMake Language Lists>` of CMake language
files to include as part of the very first :command:`project` call.
The files will be included immediately after the toolchain file has been read
(if one is specified) and platform variables have been set, but before any
languages have been enabled. Therefore, language-specific variables,
including things like :variable:`CMAKE_<LANG>_COMPILER`, might not be set.
See :ref:`Code Injection` for a more detailed discussion of files potentially
included during a :command:`project` call.

.. versionadded:: 3.29
  This variable can also now refer to module names to be found in
  :variable:`CMAKE_MODULE_PATH` or builtin to CMake.

This variable is intended for specifying files that perform one-time setup
for the build. It provides an injection point for things like configuring
package managers, adding logic the user shares between projects (e.g. defining
their own custom build types), and so on. It is primarily for users to add
things specific to their environment, but not for specifying the toolchain
details (use :variable:`CMAKE_TOOLCHAIN_FILE` for that).

By default, this variable is empty.  It is intended to be set by the user.

See also the :variable:`CMAKE_PROJECT_INCLUDE`,
:variable:`CMAKE_PROJECT_INCLUDE_BEFORE`,
:variable:`CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE`, and
:variable:`CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE_BEFORE` variables.

repo_name: lazytadpole/codenamesilverfish

license: mit


code:
CMAKE_PROJECT_VERSION
---------------------

.. versionadded:: 3.12

The version of the top level project.

This variable holds the version of the project as specified in the top
level CMakeLists.txt file by a :command:`project` command.  In the event that
the top level CMakeLists.txt contains multiple :command:`project` calls,
the most recently called one from that top level CMakeLists.txt will determine
the value that ``CMAKE_PROJECT_VERSION`` contains.  For example, consider
the following top level CMakeLists.txt:

.. code-block:: cmake

  cmake_minimum_required(VERSION 3.0)
  project(First VERSION 1.2.3)
  project(Second VERSION 3.4.5)
  add_subdirectory(sub)
  project(Third VERSION 6.7.8)

And ``sub/CMakeLists.txt`` with the following contents:

.. code-block:: cmake

  project(SubProj VERSION 1)
  message("CMAKE_PROJECT_VERSION = ${CMAKE_PROJECT_VERSION}")

The most recently seen :command:`project` command from the top level
CMakeLists.txt would be ``project(Second ...)``, so this will print::

  CMAKE_PROJECT_VERSION = 3.4.5

To obtain the version from the most recent call to :command:`project` in
the current directory scope or above, see the :variable:`PROJECT_VERSION`
variable.


code:
CMAKE_PROJECT_VERSION_MAJOR
---------------------------

.. versionadded:: 3.12

The major version of the top level project.

This variable holds the major version of the project as specified in the top
level CMakeLists.txt file by a :command:`project` command. Please see
:variable:`CMAKE_PROJECT_VERSION` documentation for the behavior when
multiple :command:`project` commands are used in the sources.


code:
CMAKE_PROJECT_VERSION_MINOR
---------------------------

.. versionadded:: 3.12

The minor version of the top level project.

This variable holds the minor version of the project as specified in the top
level CMakeLists.txt file by a :command:`project` command. Please see
:variable:`CMAKE_PROJECT_VERSION` documentation for the behavior when
multiple :command:`project` commands are used in the sources.


code:
CMAKE_PROJECT_VERSION_PATCH
---------------------------

.. versionadded:: 3.12

The patch version of the top level project.

This variable holds the patch version of the project as specified in the top
level CMakeLists.txt file by a :command:`project` command. Please see
:variable:`CMAKE_PROJECT_VERSION` documentation for the behavior when
multiple :command:`project` commands are used in the sources.


code:
CMAKE_PROJECT_VERSION_TWEAK
---------------------------

.. versionadded:: 3.12

The tweak version of the top level project.

This variable holds the tweak version of the project as specified in the top
level CMakeLists.txt file by a :command:`project` command. Please see
:variable:`CMAKE_PROJECT_VERSION` documentation for the behavior when
multiple :command:`project` commands are used in the sources.


code:
CMAKE_RANLIB
------------

Name of randomizing tool for static libraries.

This specifies name of the program that randomizes libraries on UNIX,
not used on Windows, but may be present.


code:
CMAKE_REQUIRE_FIND_PACKAGE_<PackageName>
----------------------------------------

.. versionadded:: 3.22

Variable for making :command:`find_package` call ``REQUIRED``.

Every non-``REQUIRED`` :command:`find_package` call in a project can be
turned into ``REQUIRED`` by setting the variable
``CMAKE_REQUIRE_FIND_PACKAGE_<PackageName>`` to ``TRUE``.
This can be used to assert assumptions about build environment and to
ensure the build will fail early if they do not hold.

Note that setting this variable to true breaks some commonly used patterns.
Multiple calls to :command:`find_package` are sometimes used to obtain a
different search order to the default.
For example, projects can force checking a known path for a particular
package first before searching any of the other default search paths:

.. code:: cmake

  find_package(something PATHS /some/local/path NO_DEFAULT_PATH)
  find_package(something)

In the above, the first call looks for the ``something`` package in a specific
directory.  If ``CMAKE_REQUIRE_FIND_PACKAGE_something`` is set to true, then
this first call must succeed, otherwise a fatal error occurs.  The second call
never gets a chance to provide a fall-back to using the default search
locations.

A similar pattern is used even by some of CMake's own Find modules to search
for a config package first:

.. code:: cmake

  find_package(something CONFIG QUIET)
  if(NOT something_FOUND)
    # Fall back to searching using typical Find module logic...
  endif()

Again, if ``CMAKE_REQUIRE_FIND_PACKAGE_something`` is true, the first call
must succeed.  It effectively means a config package must be found for the
dependency, and the Find module logic is never used.

See also the :variable:`CMAKE_DISABLE_FIND_PACKAGE_<PackageName>` variable.


code:
CMAKE_ROOT
----------

Install directory for running cmake.

This is the install root for the running CMake and the ``Modules``
directory can be found here.  This is commonly used in this format:
``${CMAKE_ROOT}/Modules``


code:
CMAKE_RULE_MESSAGES
-------------------

.. versionadded:: 3.13

Specify whether to report a message for each make rule.

If set in the cache it is used to initialize the value of the :prop_gbl:`RULE_MESSAGES` property.
Users may disable the option in their local build tree to disable granular messages
and report only as each target completes in Makefile builds.


code:
CMAKE_RUNTIME_OUTPUT_DIRECTORY
------------------------------

Where to put all the :ref:`RUNTIME <Runtime Output Artifacts>`
target files when built.

This variable is used to initialize the :prop_tgt:`RUNTIME_OUTPUT_DIRECTORY`
property on all the targets.  See that target property for additional
information.


code:
CMAKE_RUNTIME_OUTPUT_DIRECTORY_<CONFIG>
---------------------------------------

.. versionadded:: 3.3

Where to put all the :ref:`RUNTIME <Runtime Output Artifacts>`
target files when built for a specific configuration.

This variable is used to initialize the
:prop_tgt:`RUNTIME_OUTPUT_DIRECTORY_<CONFIG>` property on all the targets.
See that target property for additional information.


code:
CMAKE_SCRIPT_MODE_FILE
----------------------

Full path to the :option:`cmake -P` script file currently being
processed.

When run in :option:`cmake -P` script mode, CMake sets this variable to
the full path of the script file.  When run to configure a ``CMakeLists.txt``
file, this variable is not set.


code:
CMAKE_SHARED_LIBRARY_ENABLE_EXPORTS
-----------------------------------

.. versionadded:: 3.27

Specify whether shared library generates an import file.

This variable is used to initialize the :prop_tgt:`ENABLE_EXPORTS` target
property for shared library targets when they are created by calls to the
:command:`add_library` command.  See the property documentation for details.


code:
CMAKE_SHARED_LIBRARY_PREFIX
---------------------------

The prefix for shared libraries that you link to.

The prefix to use for the name of a shared library, ``lib`` on UNIX.

``CMAKE_SHARED_LIBRARY_PREFIX_<LANG>`` overrides this for language ``<LANG>``.


code:
CMAKE_SHARED_LIBRARY_SUFFIX
---------------------------

The suffix for shared libraries that you link to.

The suffix to use for the end of a shared library filename, ``.dll`` on
Windows.

``CMAKE_SHARED_LIBRARY_SUFFIX_<LANG>`` overrides this for language ``<LANG>``.


code:
CMAKE_SHARED_LINKER_FLAGS
-------------------------

Linker flags to be used to create shared libraries.

These flags will be used by the linker when creating a shared library.


code:
CMAKE_SHARED_LINKER_FLAGS_<CONFIG>
----------------------------------

Flags to be used when linking a shared library.

Same as ``CMAKE_C_FLAGS_*`` but used by the linker when creating shared
libraries.


code:
CMAKE_SHARED_LINKER_FLAGS_<CONFIG>_INIT
---------------------------------------

.. versionadded:: 3.7

Value used to initialize the :variable:`CMAKE_SHARED_LINKER_FLAGS_<CONFIG>`
cache entry the first time a build tree is configured.
This variable is meant to be set by a :variable:`toolchain file
<CMAKE_TOOLCHAIN_FILE>`.  CMake may prepend or append content to
the value based on the environment and target platform.

See also :variable:`CMAKE_SHARED_LINKER_FLAGS_INIT`.


code:
CMAKE_SHARED_LINKER_FLAGS_INIT
------------------------------

.. versionadded:: 3.7

Value used to initialize the :variable:`CMAKE_SHARED_LINKER_FLAGS`
cache entry the first time a build tree is configured.
This variable is meant to be set by a :variable:`toolchain file
<CMAKE_TOOLCHAIN_FILE>`.  CMake may prepend or append content to
the value based on the environment and target platform.

See also the configuration-specific variable
:variable:`CMAKE_SHARED_LINKER_FLAGS_<CONFIG>_INIT`.


code:
CMAKE_SHARED_MODULE_PREFIX
--------------------------

The prefix for loadable modules that you link to.

The prefix to use for the name of a loadable module on this platform.

``CMAKE_SHARED_MODULE_PREFIX_<LANG>`` overrides this for language ``<LANG>``.


code:
CMAKE_SHARED_MODULE_SUFFIX
--------------------------

The suffix for shared libraries that you link to.

The suffix to use for the end of a loadable module filename on this
platform

``CMAKE_SHARED_MODULE_SUFFIX_<LANG>`` overrides this for language ``<LANG>``.


code:
CMAKE_SIZEOF_VOID_P
-------------------

Size of a ``void`` pointer.

This is set to the size of a pointer on the target machine, and is determined
when a compiled language is enabled.  If a 64-bit size is found, then the
library search path is modified to look for 64-bit libraries first.


code:
CMAKE_SKIP_BUILD_RPATH
----------------------

Do not include RPATHs in the build tree.

Normally CMake uses the build tree for the RPATH when building
executables etc on systems that use RPATH.  When the software is
installed the executables etc are relinked by CMake to have the
install RPATH.  If this variable is set to ``TRUE`` then the software is
always built with no RPATH.

This is used to initialize the :prop_tgt:`SKIP_BUILD_RPATH` target property
for all targets. For more information on RPATH handling see
the :prop_tgt:`INSTALL_RPATH` and :prop_tgt:`BUILD_RPATH` target properties.

See also the :variable:`CMAKE_SKIP_INSTALL_RPATH` variable.
To omit RPATH in both the build and install steps, use
:variable:`CMAKE_SKIP_RPATH` instead.


code:
CMAKE_SKIP_INSTALL_ALL_DEPENDENCY
---------------------------------

Don't make the ``install`` target depend on the ``all`` target.

By default, the ``install`` target depends on the ``all`` target.  This
has the effect, that when ``make install`` is invoked or ``INSTALL`` is
built, first the ``all`` target is built, then the installation starts.
If ``CMAKE_SKIP_INSTALL_ALL_DEPENDENCY`` is set to ``TRUE``, this
dependency is not created, so the installation process will start immediately,
independent from whether the project has been completely built or not.

See also :variable:`CMAKE_SKIP_TEST_ALL_DEPENDENCY`.


code:
CMAKE_SKIP_INSTALL_RPATH
------------------------

Do not include RPATHs in the install tree.

Normally CMake uses the build tree for the RPATH when building
executables etc on systems that use RPATH.  When the software is
installed the executables etc are relinked by CMake to have the
install RPATH.  If this variable is set to true then the software is
always installed without RPATH, even if RPATH is enabled when
building.  This can be useful for example to allow running tests from
the build directory with RPATH enabled before the installation step.

See also the :variable:`CMAKE_SKIP_BUILD_RPATH` variable.
To omit RPATH in both the build and install steps, use
:variable:`CMAKE_SKIP_RPATH` instead.

For more information on RPATH handling see the :prop_tgt:`INSTALL_RPATH`
and :prop_tgt:`BUILD_RPATH` target properties.


code:
CMAKE_SKIP_INSTALL_RULES
------------------------

Whether to disable generation of installation rules.

If ``TRUE``, CMake will neither generate installation rules nor
will it generate ``cmake_install.cmake`` files. This variable is ``FALSE`` by
default.


code:
CMAKE_SKIP_RPATH
----------------

If true, do not add run time path information.

If this is set to ``TRUE``, then the rpath information is not added to
compiled executables.  The default is to add rpath information if the
platform supports it.  This allows for easy running from the build
tree.  To omit RPATH in the install step, but not the build step, use
:variable:`CMAKE_SKIP_INSTALL_RPATH` instead. To omit RPATH in the build step,
use :variable:`CMAKE_SKIP_BUILD_RPATH`.

For more information on RPATH handling see the :prop_tgt:`INSTALL_RPATH`
and :prop_tgt:`BUILD_RPATH` target properties.


code:
CMAKE_SKIP_TEST_ALL_DEPENDENCY
------------------------------

.. versionadded:: 3.29

Control whether the ``test`` target depends on the ``all`` target.

If this variable is not defined, or is set to ``TRUE``, then the
``test`` (or ``RUN_TESTS``) target does not depend on the
``all`` (or ``ALL_BUILD``) target.  When the ``test`` target is built,
e.g., via ``make test``, the test process will start immediately,
regardless of whether the project has been completely built or not.

If ``CMAKE_SKIP_TEST_ALL_DEPENDENCY`` is explicitly set to ``FALSE``,
then the ``test`` target will depend on the ``all`` target.  When the
``test`` target is built, e.g., via ``make test``, the ``all`` target
will be built first, and then the tests will run.

See also :variable:`CMAKE_SKIP_INSTALL_ALL_DEPENDENCY`.


code:
CMAKE_SOURCE_DIR
----------------

The path to the top level of the source tree.

This is the full path to the top level of the current CMake source
tree.  For an in-source build, this would be the same as
:variable:`CMAKE_BINARY_DIR`.

When run in :option:`cmake -P` script mode, CMake sets the variables
:variable:`CMAKE_BINARY_DIR`, ``CMAKE_SOURCE_DIR``,
:variable:`CMAKE_CURRENT_BINARY_DIR` and
:variable:`CMAKE_CURRENT_SOURCE_DIR` to the current working directory.


code:
CMAKE_STAGING_PREFIX
--------------------

This variable may be set to a path to install to when cross-compiling. This can
be useful if the path in :variable:`CMAKE_SYSROOT` is read-only, or otherwise
should remain pristine.

The ``CMAKE_STAGING_PREFIX`` location is also used as a search prefix
by the ``find_*`` commands. This can be controlled by setting the
:variable:`CMAKE_FIND_NO_INSTALL_PREFIX` variable.

If any ``RPATH``/``RUNPATH`` entries passed to the linker contain the
``CMAKE_STAGING_PREFIX``, the matching path fragments are replaced
with the :variable:`CMAKE_INSTALL_PREFIX`.


code:
CMAKE_STATIC_LIBRARY_PREFIX
---------------------------

The prefix for static libraries that you link to.

The prefix to use for the name of a static library, ``lib`` on UNIX.

``CMAKE_STATIC_LIBRARY_PREFIX_<LANG>`` overrides this for language ``<LANG>``.


code:
CMAKE_STATIC_LIBRARY_SUFFIX
---------------------------

The suffix for static libraries that you link to.

The suffix to use for the end of a static library filename, ``.lib`` on
Windows.

``CMAKE_STATIC_LIBRARY_SUFFIX_<LANG>`` overrides this for language ``<LANG>``.


code:
CMAKE_STATIC_LINKER_FLAGS
-------------------------

Flags to be used to create static libraries.  These flags will be passed
to the archiver when creating a static library.

See also :variable:`CMAKE_STATIC_LINKER_FLAGS_<CONFIG>`.

.. note::
  Static libraries do not actually link.  They are essentially archives
  of object files.  The use of the name "linker" in the name of this
  variable is kept for compatibility.


code:
CMAKE_STATIC_LINKER_FLAGS_<CONFIG>
----------------------------------

Flags to be used to create static libraries.  These flags will be passed
to the archiver when creating a static library in the ``<CONFIG>``
configuration.

See also :variable:`CMAKE_STATIC_LINKER_FLAGS`.

.. note::
  Static libraries do not actually link.  They are essentially archives
  of object files.  The use of the name "linker" in the name of this
  variable is kept for compatibility.


code:
CMAKE_STATIC_LINKER_FLAGS_<CONFIG>_INIT
---------------------------------------

.. versionadded:: 3.7

Value used to initialize the :variable:`CMAKE_STATIC_LINKER_FLAGS_<CONFIG>`
cache entry the first time a build tree is configured.
This variable is meant to be set by a :variable:`toolchain file
<CMAKE_TOOLCHAIN_FILE>`.  CMake may prepend or append content to
the value based on the environment and target platform.

See also :variable:`CMAKE_STATIC_LINKER_FLAGS_INIT`.


code:
CMAKE_STATIC_LINKER_FLAGS_INIT
------------------------------

.. versionadded:: 3.7

Value used to initialize the :variable:`CMAKE_STATIC_LINKER_FLAGS`
cache entry the first time a build tree is configured.
This variable is meant to be set by a :variable:`toolchain file
<CMAKE_TOOLCHAIN_FILE>`.  CMake may prepend or append content to
the value based on the environment and target platform.

See also the configuration-specific variable
:variable:`CMAKE_STATIC_LINKER_FLAGS_<CONFIG>_INIT`.


code:
CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS
---------------------------------

.. versionadded:: 3.8

This variable contains a list of env vars as a list of tokens with the
syntax ``var=value``.

Example:

.. code-block:: cmake

  set(CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS
     "FOO=FOO1\;FOO2\;FOON"
     "BAR=BAR1\;BAR2\;BARN"
     "BAZ=BAZ1\;BAZ2\;BAZN"
     "FOOBAR=FOOBAR1\;FOOBAR2\;FOOBARN"
     "VALID="
     )

In case of malformed variables CMake will fail:

.. code-block:: cmake

  set(CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS
      "THIS_IS_NOT_VALID"
      )


code:
CMAKE_SUBLIME_TEXT_2_EXCLUDE_BUILD_TREE
---------------------------------------

.. versionadded:: 3.8

If this variable evaluates to ``ON`` at the end of the top-level
``CMakeLists.txt`` file, the :generator:`Sublime Text 2` extra generator
excludes the build tree from the ``.sublime-project`` if it is inside the
source tree.


code:
CMAKE_SUPPRESS_REGENERATION
---------------------------

.. versionadded:: 3.12

If ``CMAKE_SUPPRESS_REGENERATION`` is ``OFF``, which is default, then CMake
adds a special target on which all other targets depend that checks the build
system and optionally re-runs CMake to regenerate the build system when
the target specification source changes.

If this variable evaluates to ``ON`` at the end of the top-level
``CMakeLists.txt`` file, CMake will not add the regeneration target to the
build system or perform any build system checks.


code:
CMAKE_SYSROOT
-------------

Path to pass to the compiler in the ``--sysroot`` flag.

The ``CMAKE_SYSROOT`` content is passed to the compiler in the ``--sysroot``
flag, if supported.  The path is also stripped from the ``RPATH``/``RUNPATH``
if necessary on installation.  The ``CMAKE_SYSROOT`` is also used to prefix
paths searched by the ``find_*`` commands.

This variable may only be set in a toolchain file specified by
the :variable:`CMAKE_TOOLCHAIN_FILE` variable.

See also the :variable:`CMAKE_SYSROOT_COMPILE` and
:variable:`CMAKE_SYSROOT_LINK` variables.


code:
CMAKE_SYSROOT_COMPILE
---------------------

.. versionadded:: 3.9

Path to pass to the compiler in the ``--sysroot`` flag when compiling source
files.  This is the same as :variable:`CMAKE_SYSROOT` but is used only for
compiling sources and not linking.

This variable may only be set in a toolchain file specified by
the :variable:`CMAKE_TOOLCHAIN_FILE` variable.


code:
CMAKE_SYSROOT_LINK
------------------

.. versionadded:: 3.9

Path to pass to the compiler in the ``--sysroot`` flag when linking.  This is
the same as :variable:`CMAKE_SYSROOT` but is used only for linking and not
compiling sources.

This variable may only be set in a toolchain file specified by
the :variable:`CMAKE_TOOLCHAIN_FILE` variable.


code:
CMAKE_SYSTEM
------------

Composite name of operating system CMake is compiling for.

This variable is the composite of :variable:`CMAKE_SYSTEM_NAME` and
:variable:`CMAKE_SYSTEM_VERSION`, e.g.
``${CMAKE_SYSTEM_NAME}-${CMAKE_SYSTEM_VERSION}``.  If
:variable:`CMAKE_SYSTEM_VERSION` is not set, then this variable is
the same as :variable:`CMAKE_SYSTEM_NAME`.


code:
CMAKE_SYSTEM_APPBUNDLE_PATH
---------------------------

.. versionadded:: 3.4

Search path for macOS application bundles used by the :command:`find_program`,
and :command:`find_package` commands.  By default it contains the standard
directories for the current system.  It is *not* intended to be modified by
the project, use :variable:`CMAKE_APPBUNDLE_PATH` for this.


code:
CMAKE_SYSTEM_FRAMEWORK_PATH
---------------------------

.. versionadded:: 3.4

Search path for macOS frameworks used by the :command:`find_library`,
:command:`find_package`, :command:`find_path`, and :command:`find_file`
commands.  By default it contains the standard directories for the
current system.  It is *not* intended to be modified by the project,
use :variable:`CMAKE_FRAMEWORK_PATH` for this.


code:
CMAKE_SYSTEM_IGNORE_PATH
------------------------

.. |CMAKE_IGNORE_VAR| replace:: ``CMAKE_SYSTEM_IGNORE_PATH``
.. |CMAKE_IGNORE_PREFIX_VAR| replace:: :variable:`CMAKE_SYSTEM_IGNORE_PREFIX_PATH`
.. |CMAKE_IGNORE_NONSYSTEM_VAR| replace:: :variable:`CMAKE_IGNORE_PATH`

.. include:: IGNORE_SEARCH_PATH.txt
.. include:: IGNORE_SEARCH_LOCATIONS.txt
.. include:: IGNORE_SEARCH_SYSTEM.txt

See also the following variables:

- :variable:`CMAKE_SYSTEM_IGNORE_PREFIX_PATH`
- :variable:`CMAKE_SYSTEM_PREFIX_PATH`
- :variable:`CMAKE_SYSTEM_LIBRARY_PATH`
- :variable:`CMAKE_SYSTEM_INCLUDE_PATH`
- :variable:`CMAKE_SYSTEM_PROGRAM_PATH`


code:
CMAKE_SYSTEM_IGNORE_PREFIX_PATH
-------------------------------

.. versionadded:: 3.23

.. |CMAKE_IGNORE_VAR| replace:: ``CMAKE_SYSTEM_IGNORE_PREFIX_PATH``
.. |CMAKE_IGNORE_NONPREFIX_VAR| replace:: :variable:`CMAKE_SYSTEM_IGNORE_PATH`
.. |CMAKE_IGNORE_NONSYSTEM_VAR| replace:: :variable:`CMAKE_IGNORE_PREFIX_PATH`

.. include:: IGNORE_SEARCH_PREFIX.txt
.. include:: IGNORE_SEARCH_LOCATIONS.txt
.. include:: IGNORE_SEARCH_SYSTEM.txt

See also the following variables:

- :variable:`CMAKE_SYSTEM_IGNORE_PATH`
- :variable:`CMAKE_SYSTEM_PREFIX_PATH`
- :variable:`CMAKE_SYSTEM_LIBRARY_PATH`
- :variable:`CMAKE_SYSTEM_INCLUDE_PATH`
- :variable:`CMAKE_SYSTEM_PROGRAM_PATH`


code:
CMAKE_SYSTEM_INCLUDE_PATH
-------------------------

:ref:`Semicolon-separated list <CMake Language Lists>` of directories specifying a search path
for the :command:`find_file` and :command:`find_path` commands.  By default
this contains the standard directories for the current system.  It is *not*
intended to be modified by the project; use :variable:`CMAKE_INCLUDE_PATH` for
this.  See also :variable:`CMAKE_SYSTEM_PREFIX_PATH`.


code:
CMAKE_SYSTEM_LIBRARY_PATH
-------------------------

:ref:`Semicolon-separated list <CMake Language Lists>` of directories specifying a search path
for the :command:`find_library` command.  By default this contains the
standard directories for the current system.  It is *not* intended to be
modified by the project; use :variable:`CMAKE_LIBRARY_PATH` for this.
See also :variable:`CMAKE_SYSTEM_PREFIX_PATH`.


code:
CMAKE_SYSTEM_NAME
-----------------

The name of the operating system for which CMake is to build.
See the :variable:`CMAKE_SYSTEM_VERSION` variable for the OS version.

Note that ``CMAKE_SYSTEM_NAME`` is not set to anything by default when running
in script mode, since it's not building anything.

System Name for Host Builds
^^^^^^^^^^^^^^^^^^^^^^^^^^^

``CMAKE_SYSTEM_NAME`` is by default set to the same value as the
:variable:`CMAKE_HOST_SYSTEM_NAME` variable so that the build
targets the host system.

System Name for Cross Compiling
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

``CMAKE_SYSTEM_NAME`` may be set explicitly when first configuring a new build
tree in order to enable :ref:`cross compiling <Cross Compiling Toolchain>`.
In this case the :variable:`CMAKE_SYSTEM_VERSION` variable must also be
set explicitly.

System Names Known to CMake
^^^^^^^^^^^^^^^^^^^^^^^^^^^

The following is a list of possible values, each associated with corresponding
operating systems or environments.

========================= ======================================================
Value                     Name
========================= ======================================================
``ADSP``                  Analog Devices Audio Digital Signal Processing
``AIX``                   IBM Unix operating system
``Android``               Android operating system
``ARTOS``                 Operating system for microcontrollers
``BeOS``                  Operating system for personal computers (discontinued)
``BlueGeneL``             Blue Gene/L static environment
``BlueGeneP-dynamic``     Blue Gene/P dynamic environment
``BlueGeneP-static``      Blue Gene/P static environment
``BlueGeneQ-dynamic``     Blue Gene/Q dynamic environment
``BlueGeneQ-static``      Blue Gene/Q static environment
``BSDOS``                 BSD operating system (discontinued)
``Catamount``             Operating system for Cray XT series
``CrayLinuxEnvironment``  Cray Linux Environment
``CYGWIN``                Cygwin environment for Windows
``Darwin``                Apple stationary operating systems (macOS, OS X, etc.)
``DOS``                   MS-DOS or compatible
``DragonFly``             BSD-derived operating system
``eCos``                  Real-time embedded operating system
``Emscripten``            Compiler toolchain to WebAssembly
``Euros``                 Real-time operating system for embedded devices
``FreeBSD``               FreeBSD operating system
``Fuchsia``               Operating system by Google based on the Zircon kernel
``Generic-ADSP``          Generic ADSP (Audio DSP) environment
``Generic-ELF``           Generic ELF (Executable and Linkable Format) environment
``Generic``               Some platforms, e.g. bare metal embedded devices
``GHS-MULTI``             Green Hills Software MULTI environment
``GNU``                   GNU/Hurd-based operating system
``Haiku``                 Unix operating system inspired by BeOS
``HP-UX``                 Hewlett Packard Unix
``iOS``                   Apple mobile phone operating system
``kFreeBSD``              FreeBSD kernel with a GNU userland
``Linux``                 All Linux-based distributions
``Midipix``               POSIX-compatible layer for Windows
``MirBSD``                MirOS BSD operating system
``MP-RAS``                MP-RAS UNIX operating system
``MSYS``                  MSYS environment (MSYSTEM=MSYS)
``NetBSD``                NetBSD operating systems
``OpenBSD``               OpenBSD operating systems
``OpenVMS``               OpenVMS operating system by HP
``OS2``                   OS/2 operating system
``OSF1``                  Compaq Tru64 UNIX (formerly DEC OSF/1, Digital Unix) (discontinued)
``QNX``                   Unix-like operating system by BlackBerry
``RISCos``                RISC OS operating system
``SCO_SV``                SCO OpenServer 5
``SerenityOS``            Unix-like operating system
``SINIX``                 SINIX operating system
``SunOS``                 Oracle Solaris and all illumos operating systems
``syllable``              Syllable operating system
``Tru64``                 Compaq Tru64 UNIX (formerly DEC OSF/1) operating system
``tvOS``                  Apple TV operating system
``ULTRIX``                Unix operating system (discontinued)
``UNIX_SV``               SCO UnixWare (pre release 7)
``UnixWare``              SCO UnixWare 7
``visionOS``              Apple mixed reality operating system
``watchOS``               Apple watch operating system
``Windows``               Windows stationary operating systems
``WindowsCE``             Windows Embedded Compact
``WindowsPhone``          Windows mobile phone operating system
``WindowsStore``          Universal Windows Platform applications
``Xenix``                 SCO Xenix Unix operating system (discontinued)
========================= ======================================================

Platform-specific notes:

* MSYS2's ``msys/cmake`` package (``/usr/bin/cmake``) works only under
  ``MSYSTEM=MSYS`` environments, with system name ``MSYS``.  Under other
  environments like ``MSYSTEM=MINGW64``, use another package such
  as ``mingw64/mingw-w64-x86_64-cmake`` (``/mingw64/bin/cmake``),
  which targets ``MSYSTEM=MINGW64`` with system name ``Windows``.

* Cygwin's ``cmake`` package (``/usr/bin/cmake``) uses system name ``CYGWIN``.
  A non-cygwin CMake on Windows (e.g. ``$PROGRAMFILES/CMake/bin/cmake``)
  uses system name ``Windows`` even when it runs under a Cygwin environment.


code:
CMAKE_SYSTEM_PREFIX_PATH
------------------------

:ref:`Semicolon-separated list <CMake Language Lists>` of directories specifying installation
*prefixes* to be searched by the :command:`find_package`,
:command:`find_program`, :command:`find_library`, :command:`find_file`, and
:command:`find_path` commands.  Each command will add appropriate
subdirectories (like ``bin``, ``lib``, or ``include``) as specified in its own
documentation.

By default this contains the system directories for the current system, the
:variable:`CMAKE_INSTALL_PREFIX`, and the :variable:`CMAKE_STAGING_PREFIX`.
The installation and staging prefixes may be excluded by setting
the :variable:`CMAKE_FIND_NO_INSTALL_PREFIX` variable before the
first :command:`project` invocation.

The system directories that are contained in ``CMAKE_SYSTEM_PREFIX_PATH`` are
locations that typically include installed software. An example being
``/usr/local`` for UNIX based platforms. In addition to standard platform
locations, CMake will also add values to ``CMAKE_SYSTEM_PREFIX_PATH`` based on
environment variables. The environment variables and search locations that
CMake uses may evolve over time, as platforms and their conventions also
evolve. The following provides an indicative list of environment variables
and locations that CMake searches, but they are subject to change:

CrayLinuxEnvironment:
  * ``ENV{SYSROOT_DIR}/``
  * ``ENV{SYSROOT_DIR}/usr``
  * ``ENV{SYSROOT_DIR}/usr/local``

Darwin:
  * ``ENV{SDKROOT}/usr`` When ``CMAKE_OSX_SYSROOT`` is not explicitly specified.

OpenBSD:
  * ``ENV{LOCALBASE}``

Unix:
  * ``ENV{CONDA_PREFIX}`` when using a conda compiler

MSYSTEM environment with MinGW toolchain:
  .. versionadded:: 3.28

  * ``ENV{MSYSTEM_PREFIX}/local``
  * ``ENV{MSYSTEM_PREFIX}``

Windows:
  * ``ENV{ProgramW6432}``
  * ``ENV{ProgramFiles}``
  * ``ENV{ProgramFiles(x86)}``
  * ``ENV{SystemDrive}/Program Files``
  * ``ENV{SystemDrive}/Program Files (x86)``

``CMAKE_SYSTEM_PREFIX_PATH`` is *not* intended to be modified by the project;
use :variable:`CMAKE_PREFIX_PATH` for this.

See also :variable:`CMAKE_SYSTEM_INCLUDE_PATH`,
:variable:`CMAKE_SYSTEM_LIBRARY_PATH`, :variable:`CMAKE_SYSTEM_PROGRAM_PATH`,
and :variable:`CMAKE_SYSTEM_IGNORE_PATH`.


code:
CMAKE_SYSTEM_PROCESSOR
----------------------

When not cross-compiling, this variable has the same value as the
:variable:`CMAKE_HOST_SYSTEM_PROCESSOR` variable.  In many cases,
this will correspond to the target architecture for the build, but
this is not guaranteed.  (E.g. on Windows, the host may be ``AMD64``
even when using a MSVC ``cl`` compiler with a 32-bit target.)

When cross-compiling, a :variable:`CMAKE_TOOLCHAIN_FILE` should set
the ``CMAKE_SYSTEM_PROCESSOR`` variable to match target architecture
that it specifies (via :variable:`CMAKE_<LANG>_COMPILER` and perhaps
:variable:`CMAKE_<LANG>_COMPILER_TARGET`).


code:
CMAKE_SYSTEM_PROGRAM_PATH
-------------------------

:ref:`Semicolon-separated list <CMake Language Lists>` of directories specifying a search path
for the :command:`find_program` command.  By default this contains the
standard directories for the current system.  It is *not* intended to be
modified by the project; use :variable:`CMAKE_PROGRAM_PATH` for this.
See also :variable:`CMAKE_SYSTEM_PREFIX_PATH`.


code:
CMAKE_SYSTEM_VERSION
--------------------

The version of the operating system for which CMake is to build.
See the :variable:`CMAKE_SYSTEM_NAME` variable for the OS name.

System Version for Host Builds
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

When the :variable:`CMAKE_SYSTEM_NAME` variable takes its default value
then ``CMAKE_SYSTEM_VERSION`` is by default set to the same value as the
:variable:`CMAKE_HOST_SYSTEM_VERSION` variable so that the build targets
the host system version.

In the case of a host build then ``CMAKE_SYSTEM_VERSION`` may be set
explicitly when first configuring a new build tree in order to enable
targeting the build for a different version of the host operating system
than is actually running on the host.  This is allowed and not considered
cross compiling so long as the binaries built for the specified OS version
can still run on the host.

System Version for Cross Compiling
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

When the :variable:`CMAKE_SYSTEM_NAME` variable is set explicitly to
enable :ref:`cross compiling <Cross Compiling Toolchain>` then the
value of ``CMAKE_SYSTEM_VERSION`` must also be set explicitly to specify
the target system version.


code:
CMAKE_Swift_COMPILATION_MODE
----------------------------

.. versionadded:: 3.29

Specify how Swift compiles a target. This variable is used to initialize the
:prop_tgt:`Swift_COMPILATION_MODE` property on targets as they are created.

The allowed values are:

.. include:: ../prop_tgt/Swift_COMPILATION_MODE-VALUES.txt

Use :manual:`generator expressions <cmake-generator-expressions(7)>` to support
per-configuration specification. For example, the code:

.. code-block:: cmake

   set(CMAKE_Swift_COMPILATION_MODE
     "$<IF:$<CONFIG:Release>,wholemodule,incremental>")

sets the default Swift compilation mode to wholemodule mode when building a
release configuration and to incremental mode in other configurations.

If this variable is not set then the :prop_tgt:`Swift_COMPILATION_MODE` target
property will not be set automatically. If that property is unset then CMake
uses the default value ``incremental`` to build the Swift source files.

.. note::

   This property only has effect when policy :policy:`CMP0157` is set to ``NEW``
   prior to the first :command:`project` or :command:`enable_language` command
   that enables the Swift language.


code:
CMAKE_Swift_LANGUAGE_VERSION
----------------------------

.. versionadded:: 3.7

Set to the Swift language version number.  If not set, the oldest legacy
version known to be available in the host Xcode version is assumed:

* Swift ``4.0`` for Xcode 10.2 and above.
* Swift ``3.0`` for Xcode 8.3 and above.
* Swift ``2.3`` for Xcode 8.2 and below.


code:
CMAKE_Swift_MODULE_DIRECTORY
----------------------------

.. versionadded:: 3.15

Swift module output directory.

This variable is used to initialize the :prop_tgt:`Swift_MODULE_DIRECTORY`
property on all the targets.  See the target property for additional
information.


code:
CMAKE_Swift_NUM_THREADS
-----------------------

.. versionadded:: 3.15.1

Number of threads for parallel compilation for Swift targets.

This variable controls the number of parallel jobs that the swift driver creates
for building targets.  If not specified, it will default to the number of
logical CPUs on the host.


code:
CMAKE_TASKING_TOOLSET
---------------------

.. versionadded:: 3.25

Select the Tasking toolset which provides the compiler

Architecture compilers are provided by different toolchains with
incompatible versioning schemes.  Set this variable in a
:variable:`toolchain file <CMAKE_TOOLCHAIN_FILE>` so CMake can detect
the compiler features correctly. If no toolset is specified,
``Standalone`` is assumed.

Due to the different versioning schemes, the compiler version
(:variable:`CMAKE_<LANG>_COMPILER_VERSION`) depends on the toolset and
architecture in use. If projects can be built with multiple toolsets or
architectures, the specified ``CMAKE_TASKING_TOOLSET`` and the
automatically determined :variable:`CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID`
must be taken into account when comparing against the
:variable:`CMAKE_<LANG>_COMPILER_VERSION`.

``TriCore``
  Compilers are provided by the TriCore toolset.

``SmartCode``
  Compilers are provided by the SmartCode toolset.

``Standalone``
  Compilers are provided by the standalone toolsets.

  .. note::

    For the TriCore architecture, the compiler from the TriCore toolset is
    selected as standalone compiler.


code:
CMAKE_TEST_LAUNCHER
-------------------

.. versionadded:: 3.29

This variable is used to initialize the :prop_tgt:`TEST_LAUNCHER` target
property of executable targets as they are created.  It is used to specify
a launcher for running tests, added by the :command:`add_test` command,
that run an executable target.

If this variable contains a :ref:`semicolon-separated list <CMake Language
Lists>`, then the first value is the command and remaining values are its
arguments.

This variable can be initialized via an
:envvar:`CMAKE_TEST_LAUNCHER` environment variable.


code:
CMAKE_TLS_CAINFO
----------------

Specify the default value for the :command:`file(DOWNLOAD)` and
:command:`file(UPLOAD)` commands' ``TLS_CAINFO`` options.
It is unset by default.

This variable is also used by the :module:`ExternalProject` and
:module:`FetchContent` modules for internal calls to :command:`file(DOWNLOAD)`.


code:
CMAKE_TLS_VERIFY
----------------

Specify the default value for the :command:`file(DOWNLOAD)` and
:command:`file(UPLOAD)` commands' ``TLS_VERIFY`` options.
If not set, the default is *off*.

This variable is also used by the :module:`ExternalProject` and
:module:`FetchContent` modules for internal calls to :command:`file(DOWNLOAD)`.

TLS verification can help provide confidence that one is connecting
to the desired server.  When downloading known content, one should
also use file hashes to verify it.

.. code-block:: cmake

  set(CMAKE_TLS_VERIFY TRUE)


code:
CMAKE_TOOLCHAIN_FILE
--------------------

Path to toolchain file supplied to :manual:`cmake(1)`.

This variable is specified on the command line when cross-compiling with CMake.
It is the path to a file which is read early in the CMake run and which
specifies locations for compilers and toolchain utilities, and other target
platform and compiler related information.

Relative paths are allowed and are interpreted first as relative to the
build directory, and if not found, relative to the source directory.

This is initialized by the :envvar:`CMAKE_TOOLCHAIN_FILE` environment
variable if it is set when a new build tree is first created.

See the :variable:`CMAKE_PROJECT_TOP_LEVEL_INCLUDES` variable for setting
other things not directly related to the toolchain.


code:
CMAKE_TRY_COMPILE_CONFIGURATION
-------------------------------

Build configuration used for :command:`try_compile` and :command:`try_run`
projects.

Projects built by :command:`try_compile` and :command:`try_run` are built
synchronously during the CMake configuration step.  Therefore a specific build
configuration must be chosen even if the generated build system
supports multiple configurations.


code:
CMAKE_TRY_COMPILE_NO_PLATFORM_VARIABLES
---------------------------------------

.. versionadded:: 3.24

Set to a true value to tell the :command:`try_compile` command not
to propagate any platform variables into the test project.

The :command:`try_compile` command normally passes some CMake variables
that configure the platform and toolchain behavior into test projects.
See policy :policy:`CMP0137`.  This variable may be set to disable
that behavior.


code:
CMAKE_TRY_COMPILE_PLATFORM_VARIABLES
------------------------------------

.. versionadded:: 3.6

List of variables that the :command:`try_compile` command source file signature
must propagate into the test project in order to target the same platform as
the host project.

This variable should not be set by project code.  It is meant to be set by
CMake's platform information modules for the current toolchain, or by a
toolchain file when used with :variable:`CMAKE_TOOLCHAIN_FILE`.

Variables meaningful to CMake, such as :variable:`CMAKE_<LANG>_FLAGS`, are
propagated automatically.  The ``CMAKE_TRY_COMPILE_PLATFORM_VARIABLES``
variable may be set to pass custom variables meaningful to a toolchain file.
For example, a toolchain file may contain:

.. code-block:: cmake

  set(CMAKE_SYSTEM_NAME ...)
  set(CMAKE_TRY_COMPILE_PLATFORM_VARIABLES MY_CUSTOM_VARIABLE)
  # ... use MY_CUSTOM_VARIABLE ...

If a user passes ``-DMY_CUSTOM_VARIABLE=SomeValue`` to CMake then this
setting will be made visible to the toolchain file both for the main
project and for test projects generated by the :command:`try_compile`
command source file signature.

.. versionchanged:: 3.24
  Listed variables are propagated to the :command:`try_compile`
  :ref:`whole-project <Try Compiling Whole Projects>` signature too.
  See :policy:`CMP0137`.

.. versionadded:: 3.24
  The :variable:`CMAKE_TRY_COMPILE_NO_PLATFORM_VARIABLES` variable may be
  set to disable passing platform variables into the test project.


code:
CMAKE_TRY_COMPILE_TARGET_TYPE
-----------------------------

.. versionadded:: 3.6

Type of target generated for :command:`try_compile` calls using the
source file signature.  Valid values are:

``EXECUTABLE``
  Use :command:`add_executable` to name the source file in the
  generated project.  This is the default if no value is given.

``STATIC_LIBRARY``
  Use :command:`add_library` with the ``STATIC`` option to name the
  source file in the generated project.  This avoids running the
  linker and is intended for use with cross-compiling toolchains
  that cannot link without custom flags or linker scripts.


code:
CMAKE_TWEAK_VERSION
-------------------

Defined to ``0`` for compatibility with code written for older
CMake versions that may have defined higher values.

.. note::

  In CMake versions 2.8.2 through 2.8.12, this variable holds
  the fourth version number component of the
  :variable:`CMAKE_VERSION` variable.


code:
CMAKE_UNITY_BUILD
-----------------

.. versionadded:: 3.16

This variable is used to initialize the :prop_tgt:`UNITY_BUILD`
property of targets when they are created.  Setting it to true
enables batch compilation of multiple sources within each target.
This feature is known as a *Unity* or *Jumbo* build.

Projects should not set this variable, it is intended as a developer
control to be set on the :manual:`cmake(1)` command line or other
equivalent methods.  The developer must have the ability to enable or
disable unity builds according to the capabilities of their own machine
and compiler.

By default, this variable is not set, which will result in unity builds
being disabled.

.. note::
  This option currently does not work well in combination with
  the :variable:`CMAKE_EXPORT_COMPILE_COMMANDS` variable.


code:
CMAKE_UNITY_BUILD_BATCH_SIZE
----------------------------

.. versionadded:: 3.16

This variable is used to initialize the :prop_tgt:`UNITY_BUILD_BATCH_SIZE`
property of targets when they are created.  It specifies the default upper
limit on the number of source files that may be combined in any one unity
source file when unity builds are enabled for a target.


code:
CMAKE_UNITY_BUILD_UNIQUE_ID
---------------------------

.. versionadded:: 3.20

This variable is used to initialize the :prop_tgt:`UNITY_BUILD_UNIQUE_ID`
property of targets when they are created.  It specifies the name of the
unique identifier generated per file in a unity build.


code:
CMAKE_USER_MAKE_RULES_OVERRIDE
------------------------------

Specify a CMake file that overrides platform information.

CMake loads the specified file while enabling support for each
language from either the :command:`project` or :command:`enable_language`
commands.  It is loaded after CMake's builtin compiler and platform information
modules have been loaded but before the information is used.  The file
may set platform information variables to override CMake's defaults.
See :variable:`CMAKE_USER_MAKE_RULES_OVERRIDE_<LANG>` for the language-specific
version of this variable.

This feature is intended for use only in overriding information
variables that must be set before CMake builds its first test project
to check that the compiler for a language works.  It should not be
used to load a file in cases that a normal :command:`include` will work.  Use
it only as a last resort for behavior that cannot be achieved any
other way.  For example, one may set the
:variable:`CMAKE_C_FLAGS_INIT <CMAKE_<LANG>_FLAGS_INIT>` variable
to change the default value used to initialize the
:variable:`CMAKE_C_FLAGS <CMAKE_<LANG>_FLAGS>` variable
before it is cached.  The override file should NOT be used to set anything
that could be set after languages are enabled, such as variables like
:variable:`CMAKE_RUNTIME_OUTPUT_DIRECTORY` that affect the placement of
binaries.  Information set in the file will be used for :command:`try_compile`
and :command:`try_run` builds too.


code:
CMAKE_USER_MAKE_RULES_OVERRIDE_<LANG>
-------------------------------------

Specify a CMake file that overrides platform information for ``<LANG>``.

This is a language-specific version of
:variable:`CMAKE_USER_MAKE_RULES_OVERRIDE` loaded only when enabling language
``<LANG>``.


code:
CMAKE_USE_RELATIVE_PATHS
------------------------

This variable has no effect.  The partially implemented effect it
had in previous releases was removed in CMake 3.4.


code:
CMAKE_VERBOSE_MAKEFILE
----------------------

Enable verbose output from Makefile builds.

This variable is a cache entry initialized (to ``FALSE``) by
the :command:`project` command.  Users may enable the option
in their local build tree to get more verbose output from
Makefile builds and show each command line as it is launched.


code:
CMAKE_VERIFY_INTERFACE_HEADER_SETS
----------------------------------

.. versionadded:: 3.24

This variable is used to initialize the
:prop_tgt:`VERIFY_INTERFACE_HEADER_SETS` property of targets when they are
created.  Setting it to true enables header set verification.

Projects should not normally set this variable, it is intended as a developer
control to be set on the :manual:`cmake(1)` command line or other
equivalent methods.  The developer must have the ability to enable or
disable header set verification according to the capabilities of their own
machine and compiler.

Verification of a dependency's header sets is not typically of interest
to developers.  Therefore, :command:`FetchContent_MakeAvailable` explicitly
sets ``CMAKE_VERIFY_INTERFACE_HEADER_SETS`` to false for the duration of its
call, but restores its original value before returning.  If a project brings
a dependency directly into the main build (e.g. calling
:command:`add_subdirectory` on a vendored project from a git submodule), it
should also do likewise.  For example:

.. code:: cmake

  # Save original setting so we can restore it later
  set(want_header_set_verification ${CMAKE_VERIFY_INTERFACE_HEADER_SETS})

  # Include the vendored dependency with header set verification disabled
  set(CMAKE_VERIFY_INTERFACE_HEADER_SETS OFF)
  add_subdirectory(...)   # Vendored sources, e.g. from git submodules

  # Add the project's own sources. Restore the developer's original choice
  # for whether to enable header set verification.
  set(CMAKE_VERIFY_INTERFACE_HEADER_SETS ${want_header_set_verification})
  add_subdirectory(src)

By default, this variable is not set, which will result in header set
verification being disabled.


code:
CMAKE_VERSION
-------------

The CMake version string as three non-negative integer components
separated by ``.`` and possibly followed by ``-`` and other information.
The first two components represent the feature level and the third
component represents either a bug-fix level or development date.

Release versions and release candidate versions of CMake use the format::

  <major>.<minor>.<patch>[-rc<n>]

where the ``<patch>`` component is less than ``20000000``.  Development
versions of CMake use the format::

  <major>.<minor>.<date>[-<id>]

where the ``<date>`` component is of format ``CCYYMMDD`` and ``<id>``
may contain arbitrary text.  This represents development as of a
particular date following the ``<major>.<minor>`` feature release.

Individual component values are also available in variables:

* :variable:`CMAKE_MAJOR_VERSION`
* :variable:`CMAKE_MINOR_VERSION`
* :variable:`CMAKE_PATCH_VERSION`
* :variable:`CMAKE_TWEAK_VERSION`

Use the :command:`if` command ``VERSION_LESS``, ``VERSION_GREATER``,
``VERSION_EQUAL``, ``VERSION_LESS_EQUAL``, or ``VERSION_GREATER_EQUAL``
operators to compare version string values against ``CMAKE_VERSION`` using a
component-wise test.  Version component values may be 10 or larger so do not
attempt to compare version strings as floating-point numbers.

.. note::

  CMake versions 2.8.2 through 2.8.12 used three components for the
  feature level.  Release versions represented the bug-fix level in a
  fourth component, i.e. ``<major>.<minor>.<patch>[.<tweak>][-rc<n>]``.
  Development versions represented the development date in the fourth
  component, i.e. ``<major>.<minor>.<patch>.<date>[-<id>]``.

  CMake versions prior to 2.8.2 used three components for the
  feature level and had no bug-fix component.  Release versions
  used an even-valued second component, i.e.
  ``<major>.<even-minor>.<patch>[-rc<n>]``.  Development versions
  used an odd-valued second component with the development date as
  the third component, i.e. ``<major>.<odd-minor>.<date>``.

  The ``CMAKE_VERSION`` variable is defined by CMake 2.6.3 and higher.
  Earlier versions defined only the individual component variables.


code:
CMAKE_VISIBILITY_INLINES_HIDDEN
-------------------------------

Default value for the :prop_tgt:`VISIBILITY_INLINES_HIDDEN` target
property when a target is created.


code:
CMAKE_VS_DEBUGGER_COMMAND
-------------------------

.. versionadded:: 3.27

This variable is used to initialize the :prop_tgt:`VS_DEBUGGER_COMMAND`
property on each target as it is created.  See that target property
for additional information.


code:
CMAKE_VS_DEBUGGER_COMMAND_ARGUMENTS
-----------------------------------

.. versionadded:: 3.27

This variable is used to initialize the :prop_tgt:`VS_DEBUGGER_COMMAND_ARGUMENTS`
property on each target as it is created.  See that target property
for additional information.


code:
CMAKE_VS_DEBUGGER_ENVIRONMENT
-----------------------------

.. versionadded:: 3.27

This variable is used to initialize the :prop_tgt:`VS_DEBUGGER_ENVIRONMENT`
property on each target as it is created.  See that target property
for additional information.


code:
CMAKE_VS_DEBUGGER_WORKING_DIRECTORY
-----------------------------------

.. versionadded:: 3.27

This variable is used to initialize the :prop_tgt:`VS_DEBUGGER_WORKING_DIRECTORY`
property on each target as it is created.  See that target property
for additional information.


code:
CMAKE_VS_DEVENV_COMMAND
-----------------------

The generators for :generator:`Visual Studio 9 2008` and above set this
variable to the ``devenv.com`` command installed with the corresponding
Visual Studio version.  Note that this variable may be empty on
Visual Studio Express editions because they do not provide this tool.

This variable is not defined by other generators even if ``devenv.com``
is installed on the computer.

The :variable:`CMAKE_VS_MSBUILD_COMMAND` is also provided for
:generator:`Visual Studio 12 2013` and above.
See also the :variable:`CMAKE_MAKE_PROGRAM` variable.


code:
CMAKE_VS_GLOBALS
----------------

.. versionadded:: 3.13

List of ``Key=Value`` records to be set per target as target properties
:prop_tgt:`VS_GLOBAL_<variable>` with ``variable=Key`` and value ``Value``.

For example:

.. code-block:: cmake

  set(CMAKE_VS_GLOBALS
    "DefaultLanguage=en-US"
    "MinimumVisualStudioVersion=14.0"
    )

will set properties ``VS_GLOBAL_DefaultLanguage`` to ``en-US`` and
``VS_GLOBAL_MinimumVisualStudioVersion`` to ``14.0`` for all targets
(except for ``INTERFACE`` libraries).

This variable is meant to be set by a
:variable:`toolchain file <CMAKE_TOOLCHAIN_FILE>`.


code:
CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD
-----------------------------------------

.. versionadded:: 3.3

Include ``INSTALL`` target to default build.

In Visual Studio solution, by default the ``INSTALL`` target will not be part
of the default build. Setting this variable will enable the ``INSTALL`` target
to be part of the default build.


code:
CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD
-----------------------------------------

.. versionadded:: 3.8

Include ``PACKAGE`` target to default build.

In Visual Studio solution, by default the ``PACKAGE`` target will not be part
of the default build. Setting this variable will enable the ``PACKAGE`` target
to be part of the default build.


code:
CMAKE_VS_INTEL_Fortran_PROJECT_VERSION
--------------------------------------

When generating for :generator:`Visual Studio 9 2008` or greater with the Intel
Fortran plugin installed, this specifies the ``.vfproj`` project file format
version.  This is intended for internal use by CMake and should not be
used by project code.


code:
CMAKE_VS_JUST_MY_CODE_DEBUGGING
-------------------------------

.. versionadded:: 3.15

Enable Just My Code with Visual Studio debugger.

This variable is used to initialize the :prop_tgt:`VS_JUST_MY_CODE_DEBUGGING`
property on all targets when they are created.  See that target property for
additional information.


code:
CMAKE_VS_MSBUILD_COMMAND
------------------------

The generators for :generator:`Visual Studio 12 2013` and above set this
variable to the ``MSBuild.exe`` command installed with the corresponding
Visual Studio version.

This variable is not defined by other generators even if ``MSBuild.exe``
is installed on the computer.

The :variable:`CMAKE_VS_DEVENV_COMMAND` is also provided for the
non-Express editions of Visual Studio.
See also the :variable:`CMAKE_MAKE_PROGRAM` variable.


code:
CMAKE_VS_NO_COMPILE_BATCHING
----------------------------

.. versionadded:: 3.24

Turn off compile batching when using :ref:`Visual Studio Generators`.

This variable is used to initialize the :prop_tgt:`VS_NO_COMPILE_BATCHING`
property on all targets when they are created.  See that target property for
additional information.

Example
^^^^^^^

This shows setting the property for the target ``foo`` using the variable.

.. code-block:: cmake

  set(CMAKE_VS_NO_COMPILE_BATCHING ON)
  add_library(foo SHARED foo.cpp)


code:
CMAKE_VS_NUGET_PACKAGE_RESTORE
------------------------------

.. versionadded:: 3.23

When using a Visual Studio generator, this cache variable controls
if msbuild should automatically attempt to restore NuGet packages
prior to a build. NuGet packages can be defined using the
:prop_tgt:`VS_PACKAGE_REFERENCES` property on a target. If no
package references are defined, this setting will do nothing.

The command line option ``--resolve-package-references`` can be used
alternatively to control the resolve behavior globally. This option
will take precedence over the cache variable.

Targets that use the :prop_tgt:`DOTNET_SDK` are required to run a
restore before building. Disabling this option may cause the build
to fail in such projects.

This setting is stored as a cache entry. Default value is ``ON``.

See also the :prop_tgt:`VS_PACKAGE_REFERENCES` property.


code:
CMAKE_VS_NsightTegra_VERSION
----------------------------

.. versionadded:: 3.1

When using a Visual Studio generator with the
:variable:`CMAKE_SYSTEM_NAME` variable set to ``Android``,
this variable contains the version number of the
installed NVIDIA Nsight Tegra Visual Studio Edition.


code:
CMAKE_VS_PLATFORM_NAME
----------------------

.. versionadded:: 3.1

Visual Studio target platform name used by the current generator.

VS 8 and above allow project files to specify a target platform.
CMake provides the name of the chosen platform in this variable.
See the :variable:`CMAKE_GENERATOR_PLATFORM` variable for details.

See also the :variable:`CMAKE_VS_PLATFORM_NAME_DEFAULT` variable.


code:
CMAKE_VS_PLATFORM_NAME_DEFAULT
------------------------------

.. versionadded:: 3.14.3

Default for the Visual Studio target platform name for the current generator
without considering the value of the :variable:`CMAKE_GENERATOR_PLATFORM`
variable.  For :ref:`Visual Studio Generators` for VS 2017 and below this is
always ``Win32``.  For VS 2019 and above this is based on the host platform.

See also the :variable:`CMAKE_VS_PLATFORM_NAME` variable.


code:
CMAKE_VS_PLATFORM_TOOLSET
-------------------------

Visual Studio Platform Toolset name.

VS 10 and above use MSBuild under the hood and support multiple
compiler toolchains.  CMake may specify a toolset explicitly, such as
``v110`` for VS 11 or ``Windows7.1SDK`` for 64-bit support in VS 10
Express.  CMake provides the name of the chosen toolset in this
variable.

See the :variable:`CMAKE_GENERATOR_TOOLSET` variable for details.


code:
CMAKE_VS_PLATFORM_TOOLSET_CUDA
------------------------------

.. versionadded:: 3.9

NVIDIA CUDA Toolkit version whose Visual Studio toolset to use.

The :ref:`Visual Studio Generators` for VS 2010 and above support using
a CUDA toolset provided by a CUDA Toolkit.  The toolset version number
may be specified by a field in :variable:`CMAKE_GENERATOR_TOOLSET` of
the form ``cuda=8.0``. Or it is automatically detected if a path to
a standalone CUDA directory is specified in the form ``cuda=C:\path\to\cuda``.
If none is specified CMake will choose a default version.
CMake provides the selected CUDA toolset version in this variable.
The value may be empty if no CUDA Toolkit with Visual Studio integration
is installed.


code:
CMAKE_VS_PLATFORM_TOOLSET_CUDA_CUSTOM_DIR
-----------------------------------------

.. versionadded:: 3.16

Path to standalone NVIDIA CUDA Toolkit (eg. extracted from installer).

The :ref:`Visual Studio Generators` for VS 2010 and above support using
a standalone (non-installed) NVIDIA CUDA toolkit.  The path
may be specified by a field in :variable:`CMAKE_GENERATOR_TOOLSET` of
the form ``cuda=C:\path\to\cuda``.  The given directory must at least
contain the nvcc compiler in path ``.\bin`` and must provide Visual Studio
integration files in path ``.\extras\visual_studio_integration\
MSBuildExtensions\``. One can create a standalone CUDA toolkit directory by
either opening a installer with 7zip or copying the files that are extracted
by the running installer. The value may be empty if no path to a standalone
CUDA Toolkit was specified.


code:
CMAKE_VS_PLATFORM_TOOLSET_FORTRAN
---------------------------------

.. versionadded:: 3.29

Fortran compiler to be used by Visual Studio projects.

:ref:`Visual Studio Generators` support selecting among Fortran compilers
whose Visual Studio Integration is installed.  The compiler may be specified
by a field in :variable:`CMAKE_GENERATOR_TOOLSET` of the form ``fortran=...``.
CMake provides the selected Fortran compiler in this variable.
The value may be empty if the field was not specified.


code:
CMAKE_VS_PLATFORM_TOOLSET_HOST_ARCHITECTURE
-------------------------------------------

.. versionadded:: 3.8

Visual Studio preferred tool architecture.

The :ref:`Visual Studio Generators` for VS 2013 and above support using
either the 32-bit or 64-bit host toolchains by specifying a ``host=x86``
or ``host=x64`` value in the :variable:`CMAKE_GENERATOR_TOOLSET` option.
CMake provides the selected toolchain architecture preference in this
variable (``x86``, ``x64``, ``ARM64`` or empty).


code:
CMAKE_VS_PLATFORM_TOOLSET_VERSION
---------------------------------

.. versionadded:: 3.12

Visual Studio Platform Toolset version.

The :ref:`Visual Studio Generators` for VS 2017 and above allow to
select minor versions of the same toolset. The toolset version number
may be specified by a field in :variable:`CMAKE_GENERATOR_TOOLSET` of
the form ``version=14.11``. If none is specified CMake will choose a default
toolset. The value may be empty if no minor version was selected and the
default is used.

If the value is not empty, it is the version number that MSBuild uses in
its ``Microsoft.VCToolsVersion.*.props`` file names.

.. versionadded:: 3.19.7

   VS 16.9's toolset may also be specified as ``14.28.16.9`` because
   VS 16.10 uses the file name ``Microsoft.VCToolsVersion.14.28.16.9.props``.

Three-Component MSVC Toolset Versions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. versionadded:: 3.19.7

The ``version=`` field may be given a three-component toolset version
such as ``14.28.29910``, and CMake will convert it to the name used by
MSBuild ``Microsoft.VCToolsVersion.*.props`` files.  This is useful
to distinguish between VS 16.8's ``14.28.29333`` toolset and VS 16.9's
``14.28.29910`` toolset.  It also matches ``vcvarsall``'s ``-vcvars_ver=``
behavior.


code:
CMAKE_VS_SDK_EXCLUDE_DIRECTORIES
--------------------------------

.. versionadded:: 3.12

This variable allows to override Visual Studio default Exclude Directories.


code:
CMAKE_VS_SDK_EXECUTABLE_DIRECTORIES
-----------------------------------

.. versionadded:: 3.12

This variable allows to override Visual Studio default Executable Directories.


code:
CMAKE_VS_SDK_INCLUDE_DIRECTORIES
--------------------------------

.. versionadded:: 3.12

This variable allows to override Visual Studio default Include Directories.


code:
CMAKE_VS_SDK_LIBRARY_DIRECTORIES
--------------------------------

.. versionadded:: 3.12

This variable allows to override Visual Studio default Library Directories.


code:
CMAKE_VS_SDK_LIBRARY_WINRT_DIRECTORIES
--------------------------------------

.. versionadded:: 3.12

This variable allows to override Visual Studio default Library WinRT
Directories.


code:
CMAKE_VS_SDK_REFERENCE_DIRECTORIES
----------------------------------

.. versionadded:: 3.12

This variable allows to override Visual Studio default Reference Directories.


code:
CMAKE_VS_SDK_SOURCE_DIRECTORIES
-------------------------------

.. versionadded:: 3.12

This variable allows to override Visual Studio default Source Directories.


code:
CMAKE_VS_TARGET_FRAMEWORK_IDENTIFIER
------------------------------------

.. versionadded:: 3.22

Visual Studio target framework identifier.

In some cases, the :ref:`Visual Studio Generators` may use an explicit value
for the MSBuild ``TargetFrameworkIdentifier`` setting in ``.csproj`` files.
CMake provides the chosen value in this variable.

See also :variable:`CMAKE_VS_TARGET_FRAMEWORK_VERSION` and
:variable:`CMAKE_VS_TARGET_FRAMEWORK_TARGETS_VERSION`.


code:
CMAKE_VS_TARGET_FRAMEWORK_TARGETS_VERSION
-----------------------------------------

.. versionadded:: 3.22

Visual Studio target framework targets version.

In some cases, the :ref:`Visual Studio Generators` may use an explicit value
for the MSBuild ``TargetFrameworkTargetsVersion`` setting in ``.csproj`` files.
CMake provides the chosen value in this variable.

See also :variable:`CMAKE_VS_TARGET_FRAMEWORK_VERSION` and
:variable:`CMAKE_VS_TARGET_FRAMEWORK_IDENTIFIER`.


code:
CMAKE_VS_TARGET_FRAMEWORK_VERSION
---------------------------------

.. versionadded:: 3.22

Visual Studio target framework version.

In some cases, the :ref:`Visual Studio Generators` may use an explicit value
for the MSBuild ``TargetFrameworkVersion`` setting in ``.csproj`` files.
CMake provides the chosen value in this variable.

See the :variable:`CMAKE_DOTNET_TARGET_FRAMEWORK_VERSION` variable
and :prop_tgt:`DOTNET_TARGET_FRAMEWORK_VERSION` target property to
specify custom ``TargetFrameworkVersion`` values for project targets.

See also :variable:`CMAKE_VS_TARGET_FRAMEWORK_IDENTIFIER` and
:variable:`CMAKE_VS_TARGET_FRAMEWORK_TARGETS_VERSION`.


code:
CMAKE_VS_VERSION_BUILD_NUMBER
-----------------------------

.. versionadded:: 3.26

Visual Studio version.

:ref:`Visual Studio Generators` for VS 2017 and above set this
variable to the Visual Studio version build number in the format
``<major>.<minor>.<date>.<build>``.

.. include:: CMAKE_VS_VERSION_BUILD_NUMBER_COMPONENTS.txt

See also the :variable:`CMAKE_GENERATOR_INSTANCE` variable.


code:
The components are:

``<major>.<minor>``

  The VS major and minor version numbers.
  These are the same as the release version numbers.

``<date>``

  A build date in the format ``MMMDD``, where ``MMM`` is a month index
  since an epoch used by Microsoft, and ``DD`` is a day in that month.

``<build>``

  A build index on the day represented by ``<date>``.

The build number is reported by ``vswhere`` as ``installationVersion``.
For example, VS 16.11.10 has build number ``16.11.32126.315``.


code:
CMAKE_VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION
--------------------------------------------

.. versionadded:: 3.27

Tell :ref:`Visual Studio Generators` to use the given
Windows Target Platform Minimum Version.

This variable is used to initialize the
:prop_tgt:`VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION` property on all
targets when they are created.  See that target property for
additional information.


code:
CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION
----------------------------------------

.. versionadded:: 3.4

Visual Studio Windows Target Platform Version.

When targeting Windows 10 and above, :ref:`Visual Studio Generators` for
VS 2015 and above support specification of a Windows SDK version:

* If :variable:`CMAKE_GENERATOR_PLATFORM` specifies a ``version=`` field,
  as documented by :ref:`Visual Studio Platform Selection`, that SDK
  version is selected.

* Otherwise, if the ``WindowsSDKVersion`` environment variable
  is set to an available SDK version, that version is selected.
  This is intended for use in environments established by ``vcvarsall.bat``
  or similar scripts.

  .. versionadded:: 3.27
    This is enabled by policy :policy:`CMP0149`.

* Otherwise, if :variable:`CMAKE_SYSTEM_VERSION` is set to an available
  SDK version, that version is selected.

  .. versionchanged:: 3.27
    This is disabled by policy :policy:`CMP0149`.

* Otherwise, CMake uses the latest Windows SDK version available.

The chosen Windows target version number is provided
in ``CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION``.  If no Windows 10 SDK
is available this value will be empty.

One may set a ``CMAKE_WINDOWS_KITS_10_DIR`` *environment variable*
to an absolute path to tell CMake to look for Windows 10 SDKs in
a custom location.  The specified directory is expected to contain
``Include/10.0.*`` directories.

See also :variable:`CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM`.


code:
CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM
------------------------------------------------

.. versionadded:: 3.19

Override the :ref:`Windows 10 SDK Maximum Version for VS 2015` and beyond.

The ``CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM`` variable may
be set to a false value (e.g. ``OFF``, ``FALSE``, or ``0``) or the SDK version
to use as the maximum (e.g. ``10.0.14393.0``).  If unset, the default depends
on which version of Visual Studio is targeted by the current generator.

This can be used to exclude Windows SDK versions from consideration for
:variable:`CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION`.


code:
CMAKE_VS_WINRT_BY_DEFAULT
-------------------------

.. versionadded:: 3.13

Inform :ref:`Visual Studio Generators` for VS 2010 and above that the
target platform enables WinRT compilation by default and it needs to
be explicitly disabled if ``/ZW`` or :prop_tgt:`VS_WINRT_COMPONENT` is
omitted (as opposed to enabling it when either of those options is
present)

This makes cmake configuration consistent in terms of WinRT among
platforms - if you did not enable the WinRT compilation explicitly, it
will be disabled (by either not enabling it or explicitly disabling it)

Note: WinRT compilation is always explicitly disabled for C language
source files, even if it is expliclty enabled for a project

This variable is meant to be set by a
:variable:`toolchain file <CMAKE_TOOLCHAIN_FILE>` for such platforms.


code:
CMAKE_WARN_DEPRECATED
---------------------

Whether to issue warnings for deprecated functionality.

If not ``FALSE``, use of deprecated functionality will issue warnings.
If this variable is not set, CMake behaves as if it were set to ``TRUE``.

When running :manual:`cmake(1)`, this option can be enabled with the
:option:`-Wdeprecated <cmake -Wdeprecated>` option, or disabled with the
:option:`-Wno-deprecated <cmake -Wno-deprecated>` option.


code:
CMAKE_WARN_ON_ABSOLUTE_INSTALL_DESTINATION
------------------------------------------

Ask ``cmake_install.cmake`` script to warn each time a file with absolute
``INSTALL DESTINATION`` is encountered.

This variable is used by CMake-generated ``cmake_install.cmake`` scripts.
If one sets this variable to ``ON`` while running the script, it may get
warning messages from the script.


code:
CMAKE_WATCOM_RUNTIME_LIBRARY
----------------------------

.. versionadded:: 3.24

Select the Watcom runtime library for use by compilers targeting the Watcom ABI.
This variable is used to initialize the :prop_tgt:`WATCOM_RUNTIME_LIBRARY`
property on all targets as they are created.  It is also propagated by
calls to the :command:`try_compile` command into the test project.

The allowed values are:

.. include:: ../prop_tgt/WATCOM_RUNTIME_LIBRARY-VALUES.txt

Use :manual:`generator expressions <cmake-generator-expressions(7)>` to
support per-configuration specification.

For example, the code:

.. code-block:: cmake

  set(CMAKE_WATCOM_RUNTIME_LIBRARY "MultiThreaded")

selects for all following targets a multi-threaded statically-linked runtime
library.

If this variable is not set then the :prop_tgt:`WATCOM_RUNTIME_LIBRARY` target
property will not be set automatically.  If that property is not set then
CMake uses the default value ``MultiThreadedDLL`` on Windows and
``SingleThreaded`` on other platforms to select a Watcom runtime library.

.. note::

  This variable has effect only when policy :policy:`CMP0136` is set to ``NEW``
  prior to the first :command:`project` or :command:`enable_language` command
  that enables a language using a compiler targeting the Watcom ABI.


code:
CMAKE_WIN32_EXECUTABLE
----------------------

Default value for :prop_tgt:`WIN32_EXECUTABLE` of targets.

This variable is used to initialize the :prop_tgt:`WIN32_EXECUTABLE` property
on all the targets.  See that target property for additional information.


code:
CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS
--------------------------------

.. versionadded:: 3.4

Default value for :prop_tgt:`WINDOWS_EXPORT_ALL_SYMBOLS` target property.
This variable is used to initialize the property on each target as it is
created.


code:
CMAKE_XCODE_ATTRIBUTE_<an-attribute>
------------------------------------

.. versionadded:: 3.1

Set Xcode target attributes directly.

Tell the :generator:`Xcode` generator to set ``<an-attribute>`` to a given
value in the generated Xcode project.  Ignored on other generators.

This offers low-level control over the generated Xcode project file.
It is meant as a last resort for specifying settings that CMake does
not otherwise have a way to control.  Although this can override a
setting CMake normally produces on its own, doing so bypasses CMake's
model of the project and can break things.

See the :prop_tgt:`XCODE_ATTRIBUTE_<an-attribute>` target property
to set attributes on a specific target.

Contents of ``CMAKE_XCODE_ATTRIBUTE_<an-attribute>`` may use
"generator expressions" with the syntax ``$<...>``.  See the
:manual:`cmake-generator-expressions(7)` manual for available
expressions.  See the :manual:`cmake-buildsystem(7)` manual
for more on defining buildsystem properties.


code:
CMAKE_XCODE_BUILD_SYSTEM
------------------------

.. versionadded:: 3.19

Xcode build system selection.

The :generator:`Xcode` generator defines this variable to indicate which
variant of the Xcode build system will be used.  The value is the
version of Xcode in which the corresponding build system first became
mature enough for use by CMake.  The possible values are:

``1``
  The original Xcode build system.
  This is the default when using Xcode 11.x or below and supported
  up to Xcode 13.x.

``12``
  The Xcode "new build system" introduced by Xcode 10.
  It became mature enough for use by CMake in Xcode 12.
  This is the default when using Xcode 12.x or above.

The ``CMAKE_XCODE_BUILD_SYSTEM`` variable is informational and should not
be modified by project code.  See the :ref:`Xcode Build System Selection`
documentation section to select the Xcode build system.


code:
CMAKE_XCODE_GENERATE_SCHEME
---------------------------

.. versionadded:: 3.9

If enabled, the :generator:`Xcode` generator will generate schema files.  These
are useful to invoke analyze, archive, build-for-testing and test
actions from the command line.

This variable initializes the
:prop_tgt:`XCODE_GENERATE_SCHEME`
target property on all targets.


code:
CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY
-------------------------------------------

.. versionadded:: 3.11

If enabled, the :generator:`Xcode` generator will generate only a
single Xcode project file for the topmost :command:`project()` command
instead of generating one for every ``project()`` command.

This could be useful to speed up the CMake generation step for
large projects and to work-around a bug in the ``ZERO_CHECK`` logic.


code:
CMAKE_XCODE_LINK_BUILD_PHASE_MODE
---------------------------------

.. versionadded:: 3.19

This variable is used to initialize the
:prop_tgt:`XCODE_LINK_BUILD_PHASE_MODE` property on targets.
It affects the methods that the :generator:`Xcode` generator uses to link
different kinds of libraries.  Its default value is ``NONE``.


code:
CMAKE_XCODE_PLATFORM_TOOLSET
----------------------------

Xcode compiler selection.

:generator:`Xcode` supports selection of a compiler from one of the installed
toolsets.  CMake provides the name of the chosen toolset in this
variable, if any is explicitly selected (e.g.  via the :option:`cmake -T`
option).


code:
CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER
------------------------------------

.. versionadded:: 3.13

Whether to enable ``Address Sanitizer`` in the Diagnostics
section of the generated Xcode scheme.

This variable initializes the
:prop_tgt:`XCODE_SCHEME_ADDRESS_SANITIZER`
property on all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN
-----------------------------------------------------

.. versionadded:: 3.13

Whether to enable ``Detect use of stack after return``
in the Diagnostics section of the generated Xcode scheme.

This variable initializes the
:prop_tgt:`XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN`
property on all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_SCHEME_DEBUG_DOCUMENT_VERSIONING
--------------------------------------------

.. versionadded:: 3.16

Whether to enable
``Allow debugging when using document Versions Browser``
in the Options section of the generated Xcode scheme.

This variable initializes the
:prop_tgt:`XCODE_SCHEME_DEBUG_DOCUMENT_VERSIONING`
property on all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER
----------------------------------------------

.. versionadded:: 3.13

Whether to disable the ``Main Thread Checker``
in the Diagnostics section of the generated Xcode scheme.

This variable initializes the
:prop_tgt:`XCODE_SCHEME_DISABLE_MAIN_THREAD_CHECKER`
property on all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS
----------------------------------------

.. versionadded:: 3.13

Whether to enable ``Dynamic Library Loads``
in the Diagnostics section of the generated Xcode scheme.

This variable initializes the
:prop_tgt:`XCODE_SCHEME_DYNAMIC_LIBRARY_LOADS`
property on all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE
-------------------------------------------

.. versionadded:: 3.13

Whether to enable ``Dynamic Linker API usage``
in the Diagnostics section of the generated Xcode scheme.

This variable initializes the
:prop_tgt:`XCODE_SCHEME_DYNAMIC_LINKER_API_USAGE`
property on all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_SCHEME_ENABLE_GPU_API_VALIDATION
--------------------------------------------

.. versionadded:: 3.25

Property value for ``Metal: API Validation`` in the Options section of
the generated Xcode scheme.

This variable initializes the
:prop_tgt:`XCODE_SCHEME_ENABLE_GPU_API_VALIDATION` property on all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_SCHEME_ENABLE_GPU_FRAME_CAPTURE_MODE
------------------------------------------------

.. versionadded:: 3.23

Property value for ``GPU Frame Capture`` in the Options section of
the generated Xcode scheme. Example values are `Metal` and
`Disabled`.

This variable initializes the
:prop_tgt:`XCODE_SCHEME_ENABLE_GPU_FRAME_CAPTURE_MODE`
property on all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_SCHEME_ENABLE_GPU_SHADER_VALIDATION
-----------------------------------------------

.. versionadded:: 3.25

Property value for ``Metal: Shader Validation`` in the Options section of
the generated Xcode scheme.

This variable initializes the
:prop_tgt:`XCODE_SCHEME_ENABLE_GPU_SHADER_VALIDATION` property on all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_SCHEME_ENVIRONMENT
------------------------------

.. versionadded:: 3.17

Specify environment variables that should be added to the Arguments
section of the generated Xcode scheme.

If set to a list of environment variables and values of the form
``MYVAR=value`` those environment variables will be added to the
scheme.

This variable initializes the :prop_tgt:`XCODE_SCHEME_ENVIRONMENT`
property on all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_SCHEME_GUARD_MALLOC
-------------------------------

.. versionadded:: 3.13

Whether to enable ``Guard Malloc``
in the Diagnostics section of the generated Xcode scheme.

This variable initializes the
:prop_tgt:`XCODE_SCHEME_GUARD_MALLOC`
property on all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_SCHEME_LAUNCH_CONFIGURATION
---------------------------------------

.. versionadded:: 3.25

Set the build configuration to run the target.

This variable initializes the :prop_tgt:`XCODE_SCHEME_LAUNCH_CONFIGURATION`
property on all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_SCHEME_LAUNCH_MODE
------------------------------

.. versionadded:: 3.25

Property value for ``Launch`` in the Info section of the generated Xcode
scheme.

This variable initializes the :prop_tgt:`XCODE_SCHEME_LAUNCH_MODE` property on
all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP
-------------------------------------------

.. versionadded:: 3.13

Whether to enable the ``Main Thread Checker`` option
``Pause on issues``
in the Diagnostics section of the generated Xcode scheme.

This variable initializes the
:prop_tgt:`XCODE_SCHEME_MAIN_THREAD_CHECKER_STOP`
property on all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_SCHEME_MALLOC_GUARD_EDGES
-------------------------------------

.. versionadded:: 3.13

Whether to enable ``Malloc Guard Edges``
in the Diagnostics section of the generated Xcode scheme.

This variable initializes the
:prop_tgt:`XCODE_SCHEME_MALLOC_GUARD_EDGES`
property on all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_SCHEME_MALLOC_SCRIBBLE
----------------------------------

.. versionadded:: 3.13

Whether to enable ``Malloc Scribble``
in the Diagnostics section of the generated Xcode scheme.

This variable initializes the
:prop_tgt:`XCODE_SCHEME_MALLOC_SCRIBBLE`
property on all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_SCHEME_MALLOC_STACK
-------------------------------

.. versionadded:: 3.13

Whether to enable ``Malloc Stack`` in the Diagnostics
section of the generated Xcode scheme.

This variable initializes the
:prop_tgt:`XCODE_SCHEME_MALLOC_STACK`
property on all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_SCHEME_THREAD_SANITIZER
-----------------------------------

.. versionadded:: 3.13

Whether to enable ``Thread Sanitizer`` in the Diagnostics
section of the generated Xcode scheme.

This variable initializes the
:prop_tgt:`XCODE_SCHEME_THREAD_SANITIZER`
property on all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_SCHEME_THREAD_SANITIZER_STOP
----------------------------------------

.. versionadded:: 3.13

Whether to enable ``Thread Sanitizer - Pause on issues``
in the Diagnostics section of the generated Xcode scheme.

This variable initializes the
:prop_tgt:`XCODE_SCHEME_THREAD_SANITIZER_STOP`
property on all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER
------------------------------------------------

.. versionadded:: 3.13

Whether to enable ``Undefined Behavior Sanitizer``
in the Diagnostics section of the generated Xcode scheme.

This variable initializes the
:prop_tgt:`XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER`
property on all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP
-----------------------------------------------------

.. versionadded:: 3.13

Whether to enable ``Undefined Behavior Sanitizer`` option
``Pause on issues``
in the Diagnostics section of the generated Xcode scheme.

This variable initializes the
:prop_tgt:`XCODE_SCHEME_UNDEFINED_BEHAVIOUR_SANITIZER_STOP`
property on all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_SCHEME_WORKING_DIRECTORY
------------------------------------

.. versionadded:: 3.17

Specify the ``Working Directory`` of the *Run* and *Profile*
actions in the generated Xcode scheme.

This variable initializes the
:prop_tgt:`XCODE_SCHEME_WORKING_DIRECTORY`
property on all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_SCHEME_ZOMBIE_OBJECTS
---------------------------------

.. versionadded:: 3.13

Whether to enable ``Zombie Objects``
in the Diagnostics section of the generated Xcode scheme.

This variable initializes the
:prop_tgt:`XCODE_SCHEME_ZOMBIE_OBJECTS`
property on all targets.

Please refer to the :prop_tgt:`XCODE_GENERATE_SCHEME` target property
documentation to see all Xcode schema related properties.


code:
CMAKE_XCODE_XCCONFIG
--------------------

.. versionadded:: 3.24

If set, the :generator:`Xcode` generator will register the specified
file as a global XCConfig file. For target-level XCConfig files see
the :prop_tgt:`XCODE_XCCONFIG` target property.

This feature is intended to ease migration from native Xcode projects
to CMake projects.

Contents of ``CMAKE_XCODE_XCCONFIG`` may use
:manual:`generator expressions <cmake-generator-expressions(7)>`.


code:
CPACK_ABSOLUTE_DESTINATION_FILES
--------------------------------

List of files which have been installed using an ``ABSOLUTE DESTINATION`` path.

This variable is a Read-Only variable which is set internally by CPack
during installation and before packaging using
:variable:`CMAKE_ABSOLUTE_DESTINATION_FILES` defined in ``cmake_install.cmake``
scripts.  The value can be used within CPack project configuration
file and/or ``CPack<GEN>.cmake`` file of ``<GEN>`` generator.


code:
CPACK_COMPONENT_INCLUDE_TOPLEVEL_DIRECTORY
------------------------------------------

Boolean toggle to include/exclude top level directory (component case).

Similar usage as :variable:`CPACK_INCLUDE_TOPLEVEL_DIRECTORY` but for the
component case.  See :variable:`CPACK_INCLUDE_TOPLEVEL_DIRECTORY`
documentation for the detail.


code:
CPACK_CUSTOM_INSTALL_VARIABLES
------------------------------

.. versionadded:: 3.21

CPack variables (set via e.g. :option:`cpack -D`, ``CPackConfig.cmake`` or
:variable:`CPACK_PROJECT_CONFIG_FILE` scripts) are not directly visible in
installation scripts.  Instead, one can pass a list of ``varName=value``
pairs in the ``CPACK_CUSTOM_INSTALL_VARIABLES`` variable.  At install time,
each list item will result in a variable of the specified name (``varName``)
being set to the given ``value``.  The ``=`` can be omitted for an empty
``value``.

``CPACK_CUSTOM_INSTALL_VARIABLES`` allows the packaging installation to be
influenced by the user or driving script at CPack runtime without having to
regenerate the install scripts.

Example
"""""""

.. code-block:: cmake

  install(FILES large.txt DESTINATION data)

  install(CODE [[
    if(ENABLE_COMPRESSION)
      # "run-compressor" is a fictional tool that produces
      # large.txt.xz from large.txt and then removes the input file
      execute_process(COMMAND run-compressor $ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/large.txt)
    endif()
  ]])

With the above example snippet, :manual:`cpack <cpack(1)>` will by default
run the installation script with ``ENABLE_COMPRESSION`` unset, resulting in
a package containing the uncompressed ``large.txt``.  This can be overridden
when invoking :manual:`cpack <cpack(1)>` like so:

.. code-block:: shell

  cpack -D "CPACK_CUSTOM_INSTALL_VARIABLES=ENABLE_COMPRESSION=TRUE"

The installation script will then run with ``ENABLE_COMPRESSION`` set to
``TRUE``, resulting in a package containing the compressed ``large.txt.xz``
instead.


code:
CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION
-------------------------------------------

Ask CPack to error out as soon as a file with absolute ``INSTALL DESTINATION``
is encountered.

The fatal error is emitted before the installation of the offending
file takes place.  Some CPack generators, like ``NSIS``, enforce this
internally.  This variable triggers the definition
of :variable:`CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION` when CPack
runs.


code:
CPACK_INCLUDE_TOPLEVEL_DIRECTORY
--------------------------------

Boolean toggle to include/exclude top level directory.

When preparing a package CPack installs the item under the so-called
top level directory.  The purpose of is to include (set to ``1`` or ``ON`` or
``TRUE``) the top level directory in the package or not (set to ``0`` or
``OFF`` or ``FALSE``).

Each CPack generator has a built-in default value for this variable.
E.g.  Archive generators (ZIP, TGZ, ...) includes the top level
whereas RPM or DEB don't.  The user may override the default value by
setting this variable.

There is a similar variable
:variable:`CPACK_COMPONENT_INCLUDE_TOPLEVEL_DIRECTORY` which may be used
to override the behavior for the component packaging
case which may have different default value for historical (now
backward compatibility) reason.


code:
CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS
-------------------------------------------

.. versionadded:: 3.11

Default permissions for implicitly created directories during packaging.

This variable serves the same purpose during packaging as the
:variable:`CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS` variable
serves during installation (e.g. ``make install``).

If `include(CPack)` is used then by default this variable is set to the content
of :variable:`CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS`.


code:
CPACK_PACKAGING_INSTALL_PREFIX
------------------------------

The prefix used in the built package.

Each CPack generator has a default value (like ``/usr``).  This default
value may be overwritten from the ``CMakeLists.txt`` or the :manual:`cpack(1)`
command line by setting an alternative value.  Example:

::

  set(CPACK_PACKAGING_INSTALL_PREFIX "/opt")

This is not the same purpose as :variable:`CMAKE_INSTALL_PREFIX` which is used
when installing from the build tree without building a package.


code:
CPACK_SET_DESTDIR
-----------------

Boolean toggle to make CPack use ``DESTDIR`` mechanism when packaging.

``DESTDIR`` means DESTination DIRectory.  It is commonly used by makefile
users in order to install software at non-default location.  It is a
basic relocation mechanism that should not be used on Windows (see
:variable:`CMAKE_INSTALL_PREFIX` documentation).  It is usually invoked like
this:

::

 make DESTDIR=/home/john install

which will install the concerned software using the installation
prefix, e.g. ``/usr/local`` prepended with the ``DESTDIR`` value which
finally gives ``/home/john/usr/local``.  When preparing a package, CPack
first installs the items to be packaged in a local (to the build tree)
directory by using the same ``DESTDIR`` mechanism.  Nevertheless, if
``CPACK_SET_DESTDIR`` is set then CPack will set ``DESTDIR`` before doing the
local install.  The most noticeable difference is that without
``CPACK_SET_DESTDIR``, CPack uses :variable:`CPACK_PACKAGING_INSTALL_PREFIX`
as a prefix whereas with ``CPACK_SET_DESTDIR`` set, CPack will use
:variable:`CMAKE_INSTALL_PREFIX` as a prefix.

Manually setting ``CPACK_SET_DESTDIR`` may help (or simply be necessary)
if some install rules uses absolute ``DESTINATION`` (see CMake
:command:`install` command).  However, starting with CPack/CMake 2.8.3 RPM
and DEB installers tries to handle ``DESTDIR`` automatically so that it is
seldom necessary for the user to set it.


code:
CPACK_WARN_ON_ABSOLUTE_INSTALL_DESTINATION
------------------------------------------

Ask CPack to warn each time a file with absolute ``INSTALL DESTINATION`` is
encountered.

This variable triggers the definition of
:variable:`CMAKE_WARN_ON_ABSOLUTE_INSTALL_DESTINATION` when CPack runs
``cmake_install.cmake`` scripts.


code:
CTEST_BINARY_DIRECTORY
----------------------

.. versionadded:: 3.1

Specify the CTest ``BuildDirectory`` setting
in a :manual:`ctest(1)` dashboard client script.


code:
CTEST_BUILD_COMMAND
-------------------

.. versionadded:: 3.1

Specify the CTest ``MakeCommand`` setting
in a :manual:`ctest(1)` dashboard client script.


code:
CTEST_BUILD_NAME
----------------

.. versionadded:: 3.1

Specify the CTest ``BuildName`` setting
in a :manual:`ctest(1)` dashboard client script.


code:
CTEST_BZR_COMMAND
-----------------

.. versionadded:: 3.1

Specify the CTest ``BZRCommand`` setting
in a :manual:`ctest(1)` dashboard client script.


code:
CTEST_BZR_UPDATE_OPTIONS
------------------------

.. versionadded:: 3.1

Specify the CTest ``BZRUpdateOptions`` setting
in a :manual:`ctest(1)` dashboard client script.


code:
CTEST_CHANGE_ID
---------------

.. versionadded:: 3.4

Specify the CTest ``ChangeId`` setting
in a :manual:`ctest(1)` dashboard client script.

This setting allows CTest to pass arbitrary information about this
build up to CDash.  One use of this feature is to allow CDash to
post comments on your pull request if anything goes wrong with your build.


code:
CTEST_CHECKOUT_COMMAND
----------------------

.. versionadded:: 3.1

Tell the :command:`ctest_start` command how to checkout or initialize
the source directory in a :manual:`ctest(1)` dashboard client script.


code:
CTEST_CONFIGURATION_TYPE
------------------------

.. versionadded:: 3.1

Specify the CTest ``DefaultCTestConfigurationType`` setting
in a :manual:`ctest(1)` dashboard client script.

If the configuration type is set via :option:`-C \<cfg\> <ctest -C>` from the command line
then this variable is populated accordingly.


code:
CTEST_CONFIGURE_COMMAND
-----------------------

.. versionadded:: 3.1

Specify the CTest ``ConfigureCommand`` setting
in a :manual:`ctest(1)` dashboard client script.


code:
CTEST_COVERAGE_COMMAND
----------------------

.. versionadded:: 3.1

Specify the CTest ``CoverageCommand`` setting
in a :manual:`ctest(1)` dashboard client script.

Cobertura
'''''''''

Using `Cobertura`_ as the coverage generation within your multi-module
Java project can generate a series of XML files.

The Cobertura Coverage parser expects to read the coverage data from a
single XML file which contains the coverage data for all modules.
Cobertura has a program with the ability to merge given ``cobertura.ser`` files
and then another program to generate a combined XML file from the previous
merged file.  For command line testing, this can be done by hand prior to
CTest looking for the coverage files. For script builds,
set the ``CTEST_COVERAGE_COMMAND`` variable to point to a file which will
perform these same steps, such as a ``.sh`` or ``.bat`` file.

.. code-block:: cmake

  set(CTEST_COVERAGE_COMMAND .../run-coverage-and-consolidate.sh)

where the ``run-coverage-and-consolidate.sh`` script is perhaps created by
the :command:`configure_file` command and might contain the following code:

.. code-block:: bash

  #!/usr/bin/env bash
  CoberturaFiles="$(find "/path/to/source" -name "cobertura.ser")"
  SourceDirs="$(find "/path/to/source" -name "java" -type d)"
  cobertura-merge --datafile coberturamerge.ser $CoberturaFiles
  cobertura-report --datafile coberturamerge.ser --destination . \
                   --format xml $SourceDirs

The script uses ``find`` to capture the paths to all of the ``cobertura.ser``
files found below the project's source directory.  It keeps the list of files
and supplies it as an argument to the ``cobertura-merge`` program. The
``--datafile`` argument signifies where the result of the merge will be kept.

The combined ``coberturamerge.ser`` file is then used to generate the XML report
using the ``cobertura-report`` program.  The call to the cobertura-report
program requires some named arguments.

``--datafila``
  path to the merged ``.ser`` file

``--destination``
  path to put the output files(s)

``--format``
  file format to write output in: xml or html

The rest of the supplied arguments consist of the full paths to the
``/src/main/java`` directories of each module within the source tree. These
directories are needed and should not be forgotten.

.. _`Cobertura`: http://cobertura.github.io/cobertura/


code:
CTEST_COVERAGE_EXTRA_FLAGS
--------------------------

.. versionadded:: 3.1

Specify the CTest ``CoverageExtraFlags`` setting
in a :manual:`ctest(1)` dashboard client script.


code:
CTEST_CURL_OPTIONS
------------------

.. versionadded:: 3.1

Specify the CTest ``CurlOptions`` setting
in a :manual:`ctest(1)` dashboard client script.


code:
CTEST_CUSTOM_COVERAGE_EXCLUDE
-----------------------------

A list of regular expressions which will be used to exclude files by their
path from coverage output by the :command:`ctest_coverage` command.

.. include:: CTEST_CUSTOM_XXX.txt


code:
CTEST_CUSTOM_ERROR_EXCEPTION
----------------------------

A list of regular expressions which will be used to exclude when detecting
error messages in build outputs by the :command:`ctest_build` command.

.. include:: CTEST_CUSTOM_XXX.txt


code:
CTEST_CUSTOM_ERROR_MATCH
------------------------

A list of regular expressions which will be used to detect error messages in
build outputs by the :command:`ctest_build` command.

.. include:: CTEST_CUSTOM_XXX.txt


code:
CTEST_CUSTOM_ERROR_POST_CONTEXT
-------------------------------

The number of lines to include as context which follow an error message by the
:command:`ctest_build` command. The default is 10.

.. include:: CTEST_CUSTOM_XXX.txt


code:
CTEST_CUSTOM_ERROR_PRE_CONTEXT
------------------------------

The number of lines to include as context which precede an error message by
the :command:`ctest_build` command. The default is 10.

.. include:: CTEST_CUSTOM_XXX.txt