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.

repo_name: lazytadpole/codenamesilverfish

license: mit


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:
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


code:
CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE
--------------------------------------------

When saving a failing test's output, this is the maximum size, in bytes, that
will be collected by the :command:`ctest_test` command. Defaults to 307200
(300 KiB). See :variable:`CTEST_CUSTOM_TEST_OUTPUT_TRUNCATION` for possible
truncation modes.

If a test's output contains the literal string "CTEST_FULL_OUTPUT",
the output will not be truncated and may exceed the maximum size.

.. include:: CTEST_CUSTOM_XXX.txt

For controlling the output collection of passing tests, see
:variable:`CTEST_CUSTOM_MAXIMUM_PASSED_TEST_OUTPUT_SIZE`.


code:
CTEST_CUSTOM_MAXIMUM_NUMBER_OF_ERRORS
-------------------------------------

The maximum number of errors in a single build step which will be detected.
After this, the :command:`ctest_test` command will truncate the output.
Defaults to 50.

.. include:: CTEST_CUSTOM_XXX.txt


code:
CTEST_CUSTOM_MAXIMUM_NUMBER_OF_WARNINGS
---------------------------------------

The maximum number of warnings in a single build step which will be detected.
After this, the :command:`ctest_test` command will truncate the output.
Defaults to 50.

.. include:: CTEST_CUSTOM_XXX.txt


code:
CTEST_CUSTOM_MAXIMUM_PASSED_TEST_OUTPUT_SIZE
--------------------------------------------

When saving a passing test's output, this is the maximum size, in bytes, that
will be collected by the :command:`ctest_test` command. Defaults to 1024
(1 KiB). See :variable:`CTEST_CUSTOM_TEST_OUTPUT_TRUNCATION` for possible
truncation modes.

If a test's output contains the literal string "CTEST_FULL_OUTPUT",
the output will not be truncated and may exceed the maximum size.

.. include:: CTEST_CUSTOM_XXX.txt

For controlling the output collection of failing tests, see
:variable:`CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE`.


code:
CTEST_CUSTOM_MEMCHECK_IGNORE
----------------------------

A list of regular expressions to use to exclude tests during the
:command:`ctest_memcheck` command.

.. include:: CTEST_CUSTOM_XXX.txt


code:
CTEST_CUSTOM_POST_MEMCHECK
--------------------------

A list of commands to run at the end of the :command:`ctest_memcheck` command.

.. include:: CTEST_CUSTOM_XXX.txt


code:
CTEST_CUSTOM_POST_TEST
----------------------

A list of commands to run at the end of the :command:`ctest_test` command.

.. include:: CTEST_CUSTOM_XXX.txt


code:
CTEST_CUSTOM_PRE_MEMCHECK
-------------------------

A list of commands to run at the start of the :command:`ctest_memcheck`
command.

.. include:: CTEST_CUSTOM_XXX.txt


code:
CTEST_CUSTOM_PRE_TEST
----------------------

A list of commands to run at the start of the :command:`ctest_test` command.

.. include:: CTEST_CUSTOM_XXX.txt


code:
CTEST_CUSTOM_TESTS_IGNORE
-------------------------

A list of test names to be excluded from the set of tests run by the
:command:`ctest_test` command.

.. include:: CTEST_CUSTOM_XXX.txt


code:
CTEST_CUSTOM_TEST_OUTPUT_TRUNCATION
-----------------------------------

.. versionadded:: 3.24

Set the test output truncation mode in case a maximum size is configured
via the :variable:`CTEST_CUSTOM_MAXIMUM_PASSED_TEST_OUTPUT_SIZE` or
:variable:`CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE` variables.
By default the ``tail`` of the output will be truncated. Other possible
values are ``middle`` and ``head``.

.. include:: CTEST_CUSTOM_XXX.txt


code:
CTEST_CUSTOM_WARNING_EXCEPTION
------------------------------

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

.. include:: CTEST_CUSTOM_XXX.txt


code:
CTEST_CUSTOM_WARNING_MATCH
--------------------------

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

.. include:: CTEST_CUSTOM_XXX.txt


code:
CTEST_CVS_CHECKOUT
------------------

.. versionadded:: 3.1

Deprecated.  Use :variable:`CTEST_CHECKOUT_COMMAND` instead.


code:
CTEST_CVS_COMMAND
-----------------

.. versionadded:: 3.1

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


code:
CTEST_CVS_UPDATE_OPTIONS
------------------------

.. versionadded:: 3.1

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


code:
CTEST_DROP_LOCATION
-------------------

.. versionadded:: 3.1

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


code:
CTEST_DROP_METHOD
-----------------

.. versionadded:: 3.1

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


code:
CTEST_DROP_SITE
---------------

.. versionadded:: 3.1

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


code:
CTEST_DROP_SITE_CDASH
---------------------

.. versionadded:: 3.1

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


code:
CTEST_DROP_SITE_PASSWORD
------------------------

.. versionadded:: 3.1

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


code:
CTEST_DROP_SITE_USER
--------------------

.. versionadded:: 3.1

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


code:
CTEST_EXTRA_COVERAGE_GLOB
-------------------------

.. versionadded:: 3.4

A list of regular expressions which will be used to find files which should be
covered by the :command:`ctest_coverage` command.

.. include:: CTEST_CUSTOM_XXX.txt


code:
CTEST_GIT_COMMAND
-----------------

.. versionadded:: 3.1

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


code:
CTEST_GIT_INIT_SUBMODULES
-------------------------

.. versionadded:: 3.6

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


code:
CTEST_GIT_UPDATE_CUSTOM
-----------------------

.. versionadded:: 3.1

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


code:
CTEST_GIT_UPDATE_OPTIONS
------------------------

.. versionadded:: 3.1

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


code:
CTEST_HG_COMMAND
----------------

.. versionadded:: 3.1

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


code:
CTEST_HG_UPDATE_OPTIONS
-----------------------

.. versionadded:: 3.1

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


code:
CTEST_LABELS_FOR_SUBPROJECTS
----------------------------

.. versionadded:: 3.10

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


code:
CTEST_MEMORYCHECK_COMMAND
-------------------------

.. versionadded:: 3.1

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


code:
CTEST_MEMORYCHECK_COMMAND_OPTIONS
---------------------------------

.. versionadded:: 3.1

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


code:
CTEST_MEMORYCHECK_SANITIZER_OPTIONS
-----------------------------------

.. versionadded:: 3.1

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

CTest prepends correct sanitizer options ``*_OPTIONS``
environment variable to executed command. CTests adds
its own ``log_path`` to sanitizer options, don't provide your
own ``log_path``.


code:
CTEST_MEMORYCHECK_SUPPRESSIONS_FILE
-----------------------------------

.. versionadded:: 3.1

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


code:
CTEST_MEMORYCHECK_TYPE
----------------------

.. versionadded:: 3.1

Specify the CTest ``MemoryCheckType`` setting
in a :manual:`ctest(1)` dashboard client script.
Valid values are ``Valgrind``, ``Purify``, ``BoundsChecker``, ``DrMemory``,
``CudaSanitizer``, ``ThreadSanitizer``, ``AddressSanitizer``, ``LeakSanitizer``,
``MemorySanitizer`` and ``UndefinedBehaviorSanitizer``.


code:
CTEST_NIGHTLY_START_TIME
------------------------

.. versionadded:: 3.1

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

Note that this variable must always be set for a nightly build in a
dashboard script. It is needed so that nightly builds can be properly grouped
together in CDash.


code:
CTEST_P4_CLIENT
---------------

.. versionadded:: 3.1

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


code:
CTEST_P4_COMMAND
----------------

.. versionadded:: 3.1

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


code:
CTEST_P4_OPTIONS
----------------

.. versionadded:: 3.1

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


code:
CTEST_P4_UPDATE_OPTIONS
-----------------------

.. versionadded:: 3.1

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


code:
CTEST_RESOURCE_SPEC_FILE
------------------------

.. versionadded:: 3.18

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

This can also be used to specify the resource spec file from a CMake build. If
no ``RESOURCE_SPEC_FILE`` is passed to :command:`ctest_test`, and
``CTEST_RESOURCE_SPEC_FILE`` is not specified in the dashboard script, the
value of this variable from the build is used.


code:
CTEST_RUN_CURRENT_SCRIPT
------------------------

.. versionadded:: 3.11

Setting this to 0 prevents :manual:`ctest(1)` from being run again when it
reaches the end of a script run by calling :option:`ctest -S`.


code:
CTEST_SCP_COMMAND
-----------------

.. versionadded:: 3.1

Legacy option.  Not used.


code:
CTEST_SCRIPT_DIRECTORY
----------------------

The directory containing the top-level CTest script.
The concept is similar to :variable:`CMAKE_SOURCE_DIR`.


code:
CTEST_SITE
----------

.. versionadded:: 3.1

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


code:
CTEST_SOURCE_DIRECTORY
----------------------

.. versionadded:: 3.1

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


code:
CTEST_SUBMIT_INACTIVITY_TIMEOUT
-------------------------------

.. versionadded:: 3.23

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


code:
CTEST_SUBMIT_URL
----------------

.. versionadded:: 3.14

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


code:
CTEST_SVN_COMMAND
-----------------

.. versionadded:: 3.1

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


code:
CTEST_SVN_OPTIONS
-----------------

.. versionadded:: 3.1

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


code:
CTEST_SVN_UPDATE_OPTIONS
------------------------

.. versionadded:: 3.1

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


code:
CTEST_TEST_LOAD
---------------

.. versionadded:: 3.4

Specify the ``TestLoad`` setting in the :ref:`CTest Test Step`
of a :manual:`ctest(1)` dashboard client script.  This sets the
default value for the ``TEST_LOAD`` option of the :command:`ctest_test`
command.


code:
CTEST_TEST_TIMEOUT
------------------

.. versionadded:: 3.1

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


code:
CTEST_TRIGGER_SITE
------------------

.. versionadded:: 3.1

Legacy option.  Not used.


code:
CTEST_UPDATE_COMMAND
--------------------

.. versionadded:: 3.1

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


code:
CTEST_UPDATE_OPTIONS
--------------------

.. versionadded:: 3.1

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


code:
CTEST_UPDATE_VERSION_ONLY
-------------------------

.. versionadded:: 3.1

Specify the CTest :ref:`UpdateVersionOnly <UpdateVersionOnly>` setting
in a :manual:`ctest(1)` dashboard client script.


code:
CTEST_UPDATE_VERSION_OVERRIDE
-----------------------------

.. versionadded:: 3.15

Specify the CTest :ref:`UpdateVersionOverride <UpdateVersionOverride>` setting
in a :manual:`ctest(1)` dashboard client script.


code:
CTEST_USE_LAUNCHERS
-------------------

.. versionadded:: 3.1

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


code:
CYGWIN
------

``True`` for Cygwin.

Set to ``true`` when using Cygwin.


code:
ENV
---

Operator to read environment variables.

Use the syntax ``$ENV{VAR}`` to read environment variable ``VAR``.

To test whether an environment variable is defined, use the signature
``if(DEFINED ENV{<name>})`` of the :command:`if` command.

.. note::

  Environment variable names containing special characters like parentheses
  may need to be escaped.  (Policy :policy:`CMP0053` must also be enabled.)
  For example, to get the value of the Windows environment variable
  ``ProgramFiles(x86)``, use:

  .. code-block:: cmake

      set(ProgramFiles_x86 "$ENV{ProgramFiles\(x86\)}")

For general information on environment variables, see the
:ref:`Environment Variables <CMake Language Environment Variables>`
section in the :manual:`cmake-language(7)` manual.


code:
EXECUTABLE_OUTPUT_PATH
----------------------

Old executable location variable.

The target property :prop_tgt:`RUNTIME_OUTPUT_DIRECTORY` supersedes this
variable for a target if it is set.  Executable targets are otherwise placed in
this directory.


code:
GHSMULTI
--------

.. versionadded:: 3.3

``1`` when using :generator:`Green Hills MULTI` generator.

Also, Set to ``1`` when the target system is a Green Hills platform
(i.e. When :variable:`CMAKE_SYSTEM_NAME` is ``GHS-MULTI``).


code:
IOS
---

.. versionadded:: 3.14

Set to ``1`` when the target system (:variable:`CMAKE_SYSTEM_NAME`) is ``iOS``.


code:
LIBRARY_OUTPUT_PATH
-------------------

Old library location variable.

The target properties :prop_tgt:`ARCHIVE_OUTPUT_DIRECTORY`,
:prop_tgt:`LIBRARY_OUTPUT_DIRECTORY`, and :prop_tgt:`RUNTIME_OUTPUT_DIRECTORY`
supersede this variable for a target if they are set.  Library targets are
otherwise placed in this directory.


code:
LINUX
-----

.. versionadded:: 3.25

Set to true when the target system is Linux.


code:
MINGW
-----

.. versionadded:: 3.2

Set to a true value when at least one language is enabled
with a compiler targeting the GNU ABI on Windows (MinGW).

Otherwise, this variable is not set by CMake.


code:
MSVC
----

Set to ``true`` when the compiler is some version of Microsoft Visual C++
or another compiler simulating the Visual C++ ``cl`` command-line syntax.

See also the :variable:`MSVC_VERSION` variable.


code:
MSVC10
------

Discouraged.  Use the :variable:`MSVC_VERSION` variable instead.

``True`` when using the Microsoft Visual Studio ``v100`` toolset
(``cl`` version 16) or another compiler that simulates it.


code:
MSVC11
------

Discouraged.  Use the :variable:`MSVC_VERSION` variable instead.

``True`` when using the Microsoft Visual Studio ``v110`` toolset
(``cl`` version 17) or another compiler that simulates it.


code:
MSVC12
------

Discouraged.  Use the :variable:`MSVC_VERSION` variable instead.

``True`` when using the Microsoft Visual Studio ``v120`` toolset
(``cl`` version 18) or another compiler that simulates it.


code:
MSVC14
------

.. versionadded:: 3.1

Discouraged.  Use the :variable:`MSVC_VERSION` variable instead.

``True`` when using the Microsoft Visual Studio ``v140`` or ``v141``
toolset (``cl`` version 19) or another compiler that simulates it.


code:
MSVC60
------

Discouraged.  Use the :variable:`MSVC_VERSION` variable instead.

``True`` when using Microsoft Visual C++ 6.0.

Set to ``true`` when the compiler is version 6.0 of Microsoft Visual C++.


code:
MSVC70
------

Discouraged.  Use the :variable:`MSVC_VERSION` variable instead.

``True`` when using Microsoft Visual C++ 7.0.

Set to ``true`` when the compiler is version 7.0 of Microsoft Visual C++.


code:
MSVC71
------

Discouraged.  Use the :variable:`MSVC_VERSION` variable instead.

``True`` when using Microsoft Visual C++ 7.1.

Set to ``true`` when the compiler is version 7.1 of Microsoft Visual C++.


code:
MSVC80
------

Discouraged.  Use the :variable:`MSVC_VERSION` variable instead.

``True`` when using the Microsoft Visual Studio ``v80`` toolset
(``cl`` version 14) or another compiler that simulates it.


code:
MSVC90
------

Discouraged.  Use the :variable:`MSVC_VERSION` variable instead.

``True`` when using the Microsoft Visual Studio ``v90`` toolset
(``cl`` version 15) or another compiler that simulates it.


code:
MSVC_IDE
--------

``True`` when using the Microsoft Visual C++ IDE.

Set to ``true`` when the target platform is the Microsoft Visual C++ IDE, as
opposed to the command line compiler.

.. note::

  This variable is only available after compiler detection has been performed,
  so it is not available to toolchain files or before the first
  :command:`project` or :command:`enable_language` call which uses an
  MSVC-like compiler.


code:
MSVC_TOOLSET_VERSION
--------------------

.. versionadded:: 3.12

The toolset version of Microsoft Visual C/C++ being used if any.
If MSVC-like is being used, this variable is set based on the version
of the compiler as given by the :variable:`MSVC_VERSION` variable.

Known toolset version numbers are::

  80        = VS 2005 (8.0)
  90        = VS 2008 (9.0)
  100       = VS 2010 (10.0)
  110       = VS 2012 (11.0)
  120       = VS 2013 (12.0)
  140       = VS 2015 (14.0)
  141       = VS 2017 (15.0)
  142       = VS 2019 (16.0)
  143       = VS 2022 (17.0)

Compiler versions newer than those known to CMake will be reported
as the latest known toolset version.

See also the :variable:`MSVC_VERSION` variable.


code:
MSVC_VERSION
------------

The version of Microsoft Visual C/C++ being used if any.
If a compiler simulating Visual C++ is being used, this variable is set
to the toolset version simulated as given by the ``_MSC_VER``
preprocessor definition.

Known version numbers are::

  1200      = VS  6.0
  1300      = VS  7.0
  1310      = VS  7.1
  1400      = VS  8.0 (v80 toolset)
  1500      = VS  9.0 (v90 toolset)
  1600      = VS 10.0 (v100 toolset)
  1700      = VS 11.0 (v110 toolset)
  1800      = VS 12.0 (v120 toolset)
  1900      = VS 14.0 (v140 toolset)
  1910-1919 = VS 15.0 (v141 toolset)
  1920-1929 = VS 16.0 (v142 toolset)
  1930-1939 = VS 17.0 (v143 toolset)

See also the  :variable:`CMAKE_<LANG>_COMPILER_VERSION` and
:variable:`MSVC_TOOLSET_VERSION` variable.


code:
MSYS
----

.. versionadded:: 3.14

``True`` when using the :generator:`MSYS Makefiles` generator.


code:
<PROJECT-NAME>_BINARY_DIR
-------------------------

Top level binary directory for the named project.

A variable is created with the name used in the :command:`project` command,
and is the binary directory for the project.  This can be useful when
:command:`add_subdirectory` is used to connect several projects.


code:
<PROJECT-NAME>_DESCRIPTION
--------------------------

.. versionadded:: 3.12

Value given to the ``DESCRIPTION`` option of the most recent call to the
:command:`project` command with project name ``<PROJECT-NAME>``, if any.


code:
<PROJECT-NAME>_HOMEPAGE_URL
---------------------------

.. versionadded:: 3.12

Value given to the ``HOMEPAGE_URL`` option of the most recent call to the
:command:`project` command with project name ``<PROJECT-NAME>``, if any.


code:
<PROJECT-NAME>_IS_TOP_LEVEL
---------------------------

.. versionadded:: 3.21

A boolean variable indicating whether the named project was called in a top
level ``CMakeLists.txt`` file.

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

The variable value will be true in:

* the top-level directory of the project
* the top-level directory of an external project added by
  :module:`ExternalProject`
* a directory added by :command:`add_subdirectory` that does not also contain
  a :command:`project` call
* a directory added by :command:`FetchContent_MakeAvailable`,
  if the fetched content does not contain a :command:`project` call

The variable value will be false in:

* a directory added by :command:`add_subdirectory` that also contains
  a :command:`project` call
* a directory added by :command:`FetchContent_MakeAvailable`,
  if the fetched content contains a :command:`project` call


code:
<PROJECT-NAME>_SOURCE_DIR
-------------------------

Top level source directory for the named project.

A variable is created with the name used in the :command:`project` command,
and is the source directory for the project.  This can be useful when
:command:`add_subdirectory` is used to connect several projects.


code:
<PROJECT-NAME>_VERSION
----------------------

Value given to the ``VERSION`` option of the most recent call to the
:command:`project` command with project name ``<PROJECT-NAME>``, if any.

See also the component-wise version variables
:variable:`<PROJECT-NAME>_VERSION_MAJOR`,
:variable:`<PROJECT-NAME>_VERSION_MINOR`,
:variable:`<PROJECT-NAME>_VERSION_PATCH`, and
:variable:`<PROJECT-NAME>_VERSION_TWEAK`.


code:
<PROJECT-NAME>_VERSION_MAJOR
----------------------------

First version number component of the :variable:`<PROJECT-NAME>_VERSION`
variable as set by the :command:`project` command.


code:
<PROJECT-NAME>_VERSION_MINOR
----------------------------

Second version number component of the :variable:`<PROJECT-NAME>_VERSION`
variable as set by the :command:`project` command.


code:
<PROJECT-NAME>_VERSION_PATCH
----------------------------

Third version number component of the :variable:`<PROJECT-NAME>_VERSION`
variable as set by the :command:`project` command.


code:
<PROJECT-NAME>_VERSION_TWEAK
----------------------------

Fourth version number component of the :variable:`<PROJECT-NAME>_VERSION`
variable as set by the :command:`project` command.


code:
PROJECT_BINARY_DIR
------------------

Full path to build directory for project.

This is the binary directory of the most recent :command:`project` command.


code:
PROJECT_DESCRIPTION
-------------------

.. versionadded:: 3.9

Short project description given to the project command.

This is the description given to the most recently called :command:`project`
command in the current directory scope or above.  To obtain the description
of the top level project, see the :variable:`CMAKE_PROJECT_DESCRIPTION`
variable.


code:
PROJECT_HOMEPAGE_URL
--------------------

.. versionadded:: 3.12

The homepage URL of the project.

This is the homepage URL given to the most recently called :command:`project`
command in the current directory scope or above.  To obtain the homepage URL
of the top level project, see the :variable:`CMAKE_PROJECT_HOMEPAGE_URL`
variable.


code:
PROJECT_IS_TOP_LEVEL
--------------------

.. versionadded:: 3.21

A boolean variable indicating whether the most recently called
:command:`project` command in the current scope or above was in the top
level ``CMakeLists.txt`` file.

Some modules should only be included as part of the top level
``CMakeLists.txt`` file to not cause unintended side effects in the build
tree, and this variable can be used to conditionally execute such code. For
example, consider the :module:`CTest` module, which creates targets and
options:

.. code-block:: cmake

  project(MyProject)
  ...
  if(PROJECT_IS_TOP_LEVEL)
    include(CTest)
  endif()

The variable value will be true in:

* the top-level directory of the project
* the top-level directory of an external project added by
  :module:`ExternalProject`
* a directory added by :command:`add_subdirectory` that does not also contain
  a :command:`project` call
* a directory added by :command:`FetchContent_MakeAvailable`,
  if the fetched content does not contain a :command:`project` call

The variable value will be false in:

* a directory added by :command:`add_subdirectory` that also contains
  a :command:`project` call
* a directory added by :command:`FetchContent_MakeAvailable`,
  if the fetched content contains a :command:`project` call


code:
PROJECT_NAME
------------

Name of the project given to the project command.

This is the name given to the most recently called :command:`project`
command in the current directory scope or above.  To obtain the name of
the top level project, see the :variable:`CMAKE_PROJECT_NAME` variable.


code:
PROJECT_SOURCE_DIR
------------------

This is the source directory of the last call to the
:command:`project` command made in the current directory scope or one
of its parents. Note, it is not affected by calls to
:command:`project` made within a child directory scope (i.e. from
within a call to :command:`add_subdirectory` from the current scope).


code:
PROJECT_VERSION
---------------

Value given to the ``VERSION`` option of the most recent call to the
:command:`project` command, if any.

See also the component-wise version variables
:variable:`PROJECT_VERSION_MAJOR`,
:variable:`PROJECT_VERSION_MINOR`,
:variable:`PROJECT_VERSION_PATCH`, and
:variable:`PROJECT_VERSION_TWEAK`.


code:
PROJECT_VERSION_MAJOR
---------------------

First version number component of the :variable:`PROJECT_VERSION`
variable as set by the :command:`project` command.


code:
PROJECT_VERSION_MINOR
---------------------

Second version number component of the :variable:`PROJECT_VERSION`
variable as set by the :command:`project` command.


code:
PROJECT_VERSION_PATCH
---------------------

Third version number component of the :variable:`PROJECT_VERSION`
variable as set by the :command:`project` command.


code:
PROJECT_VERSION_TWEAK
---------------------

Fourth version number component of the :variable:`PROJECT_VERSION`
variable as set by the :command:`project` command.


code:
<PackageName>_ROOT
------------------

.. versionadded:: 3.12

Calls to :command:`find_package(<PackageName>)` will search in prefixes
specified by the ``<PackageName>_ROOT`` CMake variable, where
``<PackageName>`` is the (case-preserved) name given to the
:command:`find_package` call and ``_ROOT`` is literal.
For example, ``find_package(Foo)`` will search prefixes specified in the
``Foo_ROOT`` CMake variable (if set).  See policy :policy:`CMP0074`.

This variable may hold a single prefix or a
:ref:`semicolon-separated list <CMake Language Lists>` of multiple prefixes.

See also the :envvar:`<PackageName>_ROOT` environment variable.

.. variable:: <PACKAGENAME>_ROOT

  .. versionadded:: 3.27

  Calls to :command:`find_package(<PackageName>)` will also search in
  prefixes specified by the upper-case ``<PACKAGENAME>_ROOT`` CMake
  variable.  See policy :policy:`CMP0144`.


code:
UNIX
----

Set to ``True`` when the target system is UNIX or UNIX-like
(e.g. :variable:`APPLE` and :variable:`CYGWIN`).  The
:variable:`CMAKE_SYSTEM_NAME` variable should be queried if
a more specific understanding of the target system is required.


code:
WIN32
-----

Set to ``True`` when the target system is Windows, including Win64.


code:
WINCE
-----

.. versionadded:: 3.1

True when the :variable:`CMAKE_SYSTEM_NAME` variable is set
to ``WindowsCE``.


code:
WINDOWS_PHONE
-------------

.. versionadded:: 3.1

True when the :variable:`CMAKE_SYSTEM_NAME` variable is set
to ``WindowsPhone``.


code:
WINDOWS_STORE
-------------

.. versionadded:: 3.1

True when the :variable:`CMAKE_SYSTEM_NAME` variable is set
to ``WindowsStore``.


code:
XCODE
-----

.. versionadded:: 3.7

``True`` when using :generator:`Xcode` generator.


code:
XCODE_VERSION
-------------

Version of Xcode (:generator:`Xcode` generator only).

Under the :generator:`Xcode` generator, this is the version of Xcode
as specified in ``Xcode.app/Contents/version.plist`` (such as ``3.1.2``).