code:
CMAKE_COMMAND
-------------

The full path to the :manual:`cmake(1)` executable.

This is the full path to the CMake executable :manual:`cmake(1)` which is
useful from custom commands that want to use the :option:`cmake -E` option for
portable system commands.  (e.g.  ``/usr/local/bin/cmake``)


code:
CMAKE_COMPILER_2005
-------------------

Using the Visual Studio 2005 compiler from Microsoft

Set to true when using the Visual Studio 2005 compiler from Microsoft.

repo_name: lazytadpole/codenamesilverfish

license: mit


code:
CMAKE_COMPILER_IS_GNUCC
-----------------------

True if the ``C`` compiler is GNU.

This variable is deprecated.  Use
:variable:`CMAKE_C_COMPILER_ID <CMAKE_<LANG>_COMPILER_ID>` instead.


code:
CMAKE_COMPILER_IS_GNUCXX
------------------------

True if the C++ (``CXX``) compiler is GNU.

This variable is deprecated.  Use
:variable:`CMAKE_CXX_COMPILER_ID <CMAKE_<LANG>_COMPILER_ID>` instead.


code:
CMAKE_COMPILER_IS_GNUG77
------------------------

True if the ``Fortran`` compiler is GNU.

This variable is deprecated.  Use
:variable:`CMAKE_Fortran_COMPILER_ID <CMAKE_<LANG>_COMPILER_ID>` instead.


code:
CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY
----------------------------------

.. versionadded:: 3.1

Output directory for MS debug symbol ``.pdb`` files
generated by the compiler while building source files.

This variable is used to initialize the
:prop_tgt:`COMPILE_PDB_OUTPUT_DIRECTORY` property on all the targets.


code:
CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY_<CONFIG>
-------------------------------------------

.. versionadded:: 3.1

Per-configuration output directory for MS debug symbol ``.pdb`` files
generated by the compiler while building source files.

This is a per-configuration version of
:variable:`CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY`.
This variable is used to initialize the
:prop_tgt:`COMPILE_PDB_OUTPUT_DIRECTORY_<CONFIG>`
property on all the targets.


code:
CMAKE_COMPILE_WARNING_AS_ERROR
------------------------------

.. versionadded:: 3.24

Specify whether to treat warnings on compile as errors.

This variable is used to initialize the
:prop_tgt:`COMPILE_WARNING_AS_ERROR` property on all the targets.


code:
CMAKE_CONFIGURATION_TYPES
-------------------------

Specifies the available build types (configurations) on multi-config
generators (e.g. :ref:`Visual Studio <Visual Studio Generators>`,
:generator:`Xcode`, or :generator:`Ninja Multi-Config`) as a
:ref:`semicolon-separated list <CMake Language Lists>`.  Typical entries
include ``Debug``, ``Release``, ``RelWithDebInfo`` and ``MinSizeRel``,
but custom build types can also be defined.

This variable is initialized by the first :command:`project` or
:command:`enable_language` command called in a project when a new build
tree is first created.  If the :envvar:`CMAKE_CONFIGURATION_TYPES`
environment variable is set, its value is used.  Otherwise, the default
value is generator-specific.

Depending on the situation, the values in this variable may be treated
case-sensitively or case-insensitively.  See :ref:`Build Configurations`
for discussion of this and other related topics.

For single-config generators, see :variable:`CMAKE_BUILD_TYPE`.


code:
CMAKE_<CONFIG>_POSTFIX
----------------------

Default filename postfix for libraries under configuration ``<CONFIG>``.

When a non-executable target is created its :prop_tgt:`<CONFIG>_POSTFIX`
target property is initialized with the value of this variable if it is set.


code:
CMAKE_CPACK_COMMAND
-------------------

.. versionadded:: 3.13

Full path to :manual:`cpack(1)` command installed with CMake.

This is the full path to the CPack executable :manual:`cpack(1)`
that can be used for custom commands or tests to invoke
CPack commands.


code:
CMAKE_CROSSCOMPILING
--------------------

This variable is set by CMake to indicate whether it is cross compiling,
but note limitations discussed below.

This variable will be set to true by CMake if the :variable:`CMAKE_SYSTEM_NAME`
variable has been set manually (i.e. in a toolchain file or as a cache entry
from the :manual:`cmake <cmake(1)>` command line). In most cases, manually
setting :variable:`CMAKE_SYSTEM_NAME` will only be done when cross compiling
since, if not manually set, it will be given the same value as
:variable:`CMAKE_HOST_SYSTEM_NAME`, which is correct for
the non-cross-compiling case. In the event that :variable:`CMAKE_SYSTEM_NAME`
is manually set to the same value as :variable:`CMAKE_HOST_SYSTEM_NAME`, then
``CMAKE_CROSSCOMPILING`` will still be set to true.

Another case to be aware of is that builds targeting Apple platforms other than
macOS are handled differently to other cross compiling scenarios. Rather than
relying on :variable:`CMAKE_SYSTEM_NAME` to select the target platform, Apple
device builds use :variable:`CMAKE_OSX_SYSROOT` to select the appropriate SDK,
which indirectly determines the target platform. Furthermore, when using the
:generator:`Xcode` generator, developers can switch between device and
simulator builds at build time rather than having a single
choice at configure time, so the concept
of whether the build is cross compiling or not is more complex. Therefore, the
use of ``CMAKE_CROSSCOMPILING`` is not recommended for projects targeting Apple
devices.


code:
CMAKE_CROSSCOMPILING_EMULATOR
-----------------------------

.. versionadded:: 3.3

This variable is only used when :variable:`CMAKE_CROSSCOMPILING` is on. It
should point to a command on the host system that can run executable built
for the target system.

.. versionadded:: 3.15
  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.

.. versionadded:: 3.28
  This variable can be initialized via an
  :envvar:`CMAKE_CROSSCOMPILING_EMULATOR` environment variable.

The command will be used to run :command:`try_run` generated executables,
which avoids manual population of the ``TryRunResults.cmake`` file.

This variable is also used as the default value for the
:prop_tgt:`CROSSCOMPILING_EMULATOR` target property of executables.  However,
while :manual:`generator expressions <cmake-generator-expressions(7)>` are
supported by the target property (since CMake 3.29), they are *not* supported
by this variable's :command:`try_run` functionality.


code:
CMAKE_CROSS_CONFIGS
-------------------

.. versionadded:: 3.17

Specifies a :ref:`semicolon-separated list <CMake Language Lists>` of
configurations available from all ``build-<Config>.ninja`` files in the
:generator:`Ninja Multi-Config` generator.  This variable activates
cross-config mode. Targets from each config specified in this variable can be
built from any ``build-<Config>.ninja`` file. Custom commands will use the
configuration native to ``build-<Config>.ninja``. If it is set to ``all``, all
configurations from :variable:`CMAKE_CONFIGURATION_TYPES` are cross-configs. If
it is not specified, or empty, each ``build-<Config>.ninja`` file will only
contain build rules for its own configuration.

The value of this variable must be a subset of
:variable:`CMAKE_CONFIGURATION_TYPES`.


code:
CMAKE_CTEST_ARGUMENTS
---------------------

.. versionadded:: 3.17

Set this to a :ref:`semicolon-separated list <CMake Language Lists>` of
command-line arguments to pass to :manual:`ctest(1)` when running tests
through the ``test`` (or ``RUN_TESTS``) target of the generated build system.


code:
CMAKE_CTEST_COMMAND
-------------------

Full path to :manual:`ctest(1)` command installed with CMake.

This is the full path to the CTest executable :manual:`ctest(1)`
that can be used for custom commands or tests to invoke
CTest commands.


code:
CMAKE_CUDA_ARCHITECTURES
------------------------

.. versionadded:: 3.18

Default value for :prop_tgt:`CUDA_ARCHITECTURES` property of targets.

Initialized by the :envvar:`CUDAARCHS` environment variable if set.
Otherwise as follows depending on :variable:`CMAKE_CUDA_COMPILER_ID <CMAKE_<LANG>_COMPILER_ID>`:

- For ``Clang``: the oldest architecture that works.

- For ``NVIDIA``: the default architecture chosen by the compiler.
  See policy :policy:`CMP0104`.

Users are encouraged to override this, as the default varies across compilers
and compiler versions.

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

Examples
^^^^^^^^

.. code-block:: cmake

  cmake_minimum_required(VERSION)

  if(NOT DEFINED CMAKE_CUDA_ARCHITECTURES)
    set(CMAKE_CUDA_ARCHITECTURES 75)
  endif()

  project(example LANGUAGES CUDA)

``CMAKE_CUDA_ARCHITECTURES`` will default to ``75`` unless overridden by the user.


code:
CMAKE_CUDA_COMPILE_FEATURES
---------------------------

.. versionadded:: 3.17

List of features known to the CUDA compiler

These features are known to be available for use with the CUDA compiler. This
list is a subset of the features listed in the
:prop_gbl:`CMAKE_CUDA_KNOWN_FEATURES` global property.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_CUDA_EXTENSIONS
---------------------

.. versionadded:: 3.8

Default value for :prop_tgt:`CUDA_EXTENSIONS` target property if set when a
target is created.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_CUDA_HOST_COMPILER
------------------------

.. versionadded:: 3.10

This is the original CUDA-specific name for the more general
:variable:`CMAKE_<LANG>_HOST_COMPILER` variable.  See the latter
for details.


code:
CMAKE_CUDA_RESOLVE_DEVICE_SYMBOLS
---------------------------------

.. versionadded:: 3.16

Default value for :prop_tgt:`CUDA_RESOLVE_DEVICE_SYMBOLS` target
property when defined. By default this variable is not defined.

This variable is used to initialize the property on each target as
it is created.


code:
CMAKE_CUDA_RUNTIME_LIBRARY
--------------------------

.. versionadded:: 3.17

Select the CUDA runtime library for use when compiling and linking CUDA.
This variable is used to initialize the :prop_tgt:`CUDA_RUNTIME_LIBRARY`
property on all targets as they are created.

The allowed case insensitive values are:

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

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

If this variable is not set then the :prop_tgt:`CUDA_RUNTIME_LIBRARY` target
property will not be set automatically.  If that property is not set then
CMake uses an appropriate default value based on the compiler to select the
CUDA runtime library.

.. note::

  This property has effect only when the ``CUDA`` language is enabled. To
  control the CUDA runtime linking when only using the CUDA SDK with the
  ``C`` or ``C++`` language we recommend using the :module:`FindCUDAToolkit`
  module.


code:
CMAKE_CUDA_SEPARABLE_COMPILATION
--------------------------------

.. versionadded:: 3.11

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


code:
CMAKE_CUDA_STANDARD
-------------------

.. versionadded:: 3.8

Default value for :prop_tgt:`CUDA_STANDARD` target property if set when a
target is created.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_CUDA_STANDARD_REQUIRED
----------------------------

.. versionadded:: 3.8

Default value for :prop_tgt:`CUDA_STANDARD_REQUIRED` target property if set
when a target is created.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES
--------------------------------------

.. versionadded:: 3.8

When the ``CUDA`` language has been enabled, this provides a
:ref:`semicolon-separated list <CMake Language Lists>` of include directories provided
by the CUDA Toolkit.  The value may be useful for C++ source files
to include CUDA headers.


code:
CMAKE_CURRENT_BINARY_DIR
------------------------

The path to the binary directory currently being processed.

This is the full path to the build directory that is currently being
processed by cmake.  Each directory added by :command:`add_subdirectory` will
create a binary directory in the build tree, and as it is being
processed this variable will be set.  For in-source builds this is the
current source directory being processed.

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


code:
CMAKE_CURRENT_FUNCTION
----------------------

.. versionadded:: 3.17

When executing code inside a :command:`function`, this variable
contains the name of the current function.  It can be useful for
diagnostic or debug messages.

See also :variable:`CMAKE_CURRENT_FUNCTION_LIST_DIR`,
:variable:`CMAKE_CURRENT_FUNCTION_LIST_FILE` and
:variable:`CMAKE_CURRENT_FUNCTION_LIST_LINE`.


code:
CMAKE_CURRENT_FUNCTION_LIST_DIR
-------------------------------

.. versionadded:: 3.17

When executing code inside a :command:`function`, this variable
contains the full directory of the listfile that defined the current function.

It is quite common practice in CMake for modules to use some additional files,
such as templates to be copied in after substituting CMake variables.
In such cases, a function needs to know where to locate those files in a way
that doesn't depend on where the function is called.  Without
``CMAKE_CURRENT_FUNCTION_LIST_DIR``, the code to do that would typically use
the following pattern:

.. code-block:: cmake

  set(_THIS_MODULE_BASE_DIR "${CMAKE_CURRENT_LIST_DIR}")

  function(foo)
    configure_file(
      "${_THIS_MODULE_BASE_DIR}/some.template.in"
      some.output
    )
  endfunction()

Using ``CMAKE_CURRENT_FUNCTION_LIST_DIR`` inside the function instead
eliminates the need for the extra variable which would otherwise be visible
outside the function's scope.
The above example can be written in the more concise and more robust form:

.. code-block:: cmake

  function(foo)
    configure_file(
      "${CMAKE_CURRENT_FUNCTION_LIST_DIR}/some.template.in"
      some.output
    )
  endfunction()

See also :variable:`CMAKE_CURRENT_FUNCTION`,
:variable:`CMAKE_CURRENT_FUNCTION_LIST_FILE` and
:variable:`CMAKE_CURRENT_FUNCTION_LIST_LINE`.


code:
CMAKE_CURRENT_FUNCTION_LIST_FILE
--------------------------------

.. versionadded:: 3.17

When executing code inside a :command:`function`, this variable
contains the full path to the listfile that defined the current function.

See also :variable:`CMAKE_CURRENT_FUNCTION`,
:variable:`CMAKE_CURRENT_FUNCTION_LIST_DIR` and
:variable:`CMAKE_CURRENT_FUNCTION_LIST_LINE`.


code:
CMAKE_CURRENT_FUNCTION_LIST_LINE
--------------------------------

.. versionadded:: 3.17

When executing code inside a :command:`function`, this variable
contains the line number in the listfile where the current function
was defined.

See also :variable:`CMAKE_CURRENT_FUNCTION`,
:variable:`CMAKE_CURRENT_FUNCTION_LIST_DIR` and
:variable:`CMAKE_CURRENT_FUNCTION_LIST_FILE`.


code:
CMAKE_CURRENT_LIST_DIR
----------------------

Full directory of the listfile currently being processed.

As CMake processes the listfiles in your project this variable will
always be set to the directory where the listfile which is currently
being processed (:variable:`CMAKE_CURRENT_LIST_FILE`) is located.  The value
has dynamic scope.  When CMake starts processing commands in a source file
it sets this variable to the directory where this file is located.
When CMake finishes processing commands from the file it restores the
previous value.  Therefore the value of the variable inside a macro or
function is the directory of the file invoking the bottom-most entry
on the call stack, not the directory of the file containing the macro
or function definition.

See also :variable:`CMAKE_CURRENT_LIST_FILE`.


code:
CMAKE_CURRENT_LIST_FILE
-----------------------

Full path to the listfile currently being processed.

As CMake processes the listfiles in your project this variable will
always be set to the one currently being processed.  The value has
dynamic scope.  When CMake starts processing commands in a source file
it sets this variable to the location of the file.  When CMake
finishes processing commands from the file it restores the previous
value.  Therefore the value of the variable inside a macro or function
is the file invoking the bottom-most entry on the call stack, not the
file containing the macro or function definition.

See also :variable:`CMAKE_PARENT_LIST_FILE`.


code:
CMAKE_CURRENT_LIST_LINE
-----------------------

The line number of the current file being processed.

This is the line number of the file currently being processed by
cmake.

If CMake is currently processing deferred calls scheduled by
the :command:`cmake_language(DEFER)` command, this variable
evaluates to ``DEFERRED`` instead of a specific line number.


code:
CMAKE_CURRENT_SOURCE_DIR
------------------------

The path to the source directory currently being processed.

This is the full path to the source directory that is currently being
processed by cmake.

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


code:
CMAKE_CXX_COMPILE_FEATURES
--------------------------

.. versionadded:: 3.1

List of features known to the C++ compiler

These features are known to be available for use with the C++ compiler. This
list is a subset of the features listed in the
:prop_gbl:`CMAKE_CXX_KNOWN_FEATURES` global property.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_CXX_EXTENSIONS
--------------------

.. versionadded:: 3.1

Default value for :prop_tgt:`CXX_EXTENSIONS` target property if set when a
target is created.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_CXX_SCAN_FOR_MODULES
--------------------------

.. versionadded:: 3.28

Whether to scan C++ source files for module dependencies.

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


code:
CMAKE_CXX_STANDARD
------------------

.. versionadded:: 3.1

Default value for :prop_tgt:`CXX_STANDARD` target property if set when a target
is created.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_CXX_STANDARD_REQUIRED
---------------------------

.. versionadded:: 3.1

Default value for :prop_tgt:`CXX_STANDARD_REQUIRED` target property if set when
a target is created.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_C_COMPILE_FEATURES
------------------------

.. versionadded:: 3.1

List of features known to the C compiler

These features are known to be available for use with the C compiler. This
list is a subset of the features listed in the
:prop_gbl:`CMAKE_C_KNOWN_FEATURES` global property.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_C_EXTENSIONS
------------------

.. versionadded:: 3.1

Default value for :prop_tgt:`C_EXTENSIONS` target property if set when a target
is created.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_C_STANDARD
----------------

.. versionadded:: 3.1

Default value for :prop_tgt:`C_STANDARD` target property if set when a target
is created.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_C_STANDARD_REQUIRED
-------------------------

.. versionadded:: 3.1

Default value for :prop_tgt:`C_STANDARD_REQUIRED` target property if set when
a target is created.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_DEBUG_POSTFIX
-------------------

See variable :variable:`CMAKE_<CONFIG>_POSTFIX`.

This variable is a special case of the more-general
:variable:`CMAKE_<CONFIG>_POSTFIX` variable for the `DEBUG` configuration.


code:
CMAKE_DEBUG_TARGET_PROPERTIES
-----------------------------

Enables tracing output for target properties.

This variable can be populated with a list of properties to generate
debug output for when evaluating target properties.  Currently it can
only be used when evaluating:

* :prop_tgt:`AUTOUIC_OPTIONS`
* :prop_tgt:`COMPILE_DEFINITIONS`
* :prop_tgt:`COMPILE_FEATURES`
* :prop_tgt:`COMPILE_OPTIONS`
* :prop_tgt:`INCLUDE_DIRECTORIES`
* :prop_tgt:`LINK_DIRECTORIES`
* :prop_tgt:`LINK_OPTIONS`
* :prop_tgt:`POSITION_INDEPENDENT_CODE`
* :prop_tgt:`SOURCES`

target properties and any other property listed in
:prop_tgt:`COMPATIBLE_INTERFACE_STRING` and other
``COMPATIBLE_INTERFACE_`` properties.  It outputs an origin for each entry
in the target property.  Default is unset.


code:
CMAKE_DEFAULT_BUILD_TYPE
------------------------

.. versionadded:: 3.17

Specifies the configuration to use by default in a ``build.ninja`` file in the
:generator:`Ninja Multi-Config` generator. If this variable is specified,
``build.ninja`` uses build rules from ``build-<Config>.ninja`` by default. All
custom commands are executed with this configuration. If the variable is not
specified, the first item from :variable:`CMAKE_CONFIGURATION_TYPES` is used
instead.

The value of this variable must be one of the items from
:variable:`CMAKE_CONFIGURATION_TYPES`.


code:
CMAKE_DEFAULT_CONFIGS
---------------------

.. versionadded:: 3.17

Specifies a :ref:`semicolon-separated list <CMake Language Lists>` of configurations
to build for a target in ``build.ninja`` if no ``:<Config>`` suffix is specified in
the :generator:`Ninja Multi-Config` generator. If it is set to ``all``, all
configurations from :variable:`CMAKE_CROSS_CONFIGS` are used. If it is not
specified, it defaults to :variable:`CMAKE_DEFAULT_BUILD_TYPE`.

For example, if you set :variable:`CMAKE_DEFAULT_BUILD_TYPE` to ``Release``,
but set ``CMAKE_DEFAULT_CONFIGS`` to ``Debug`` or ``all``, all
``<target>`` aliases in ``build.ninja`` will resolve to ``<target>:Debug`` or
``<target>:all``, but custom commands will still use the ``Release``
configuration.

The value of this variable must be a subset of :variable:`CMAKE_CROSS_CONFIGS`
or be the same as :variable:`CMAKE_DEFAULT_BUILD_TYPE`. It must not be
specified if :variable:`CMAKE_DEFAULT_BUILD_TYPE` or
:variable:`CMAKE_CROSS_CONFIGS` is not used.


code:
CMAKE_DEPENDS_IN_PROJECT_ONLY
-----------------------------

.. versionadded:: 3.6

When set to ``TRUE`` in a directory, the build system produced by the
:ref:`Makefile Generators` is set up to only consider dependencies on source
files that appear either in the source or in the binary directories.  Changes
to source files outside of these directories will not cause rebuilds.

This should be used carefully in cases where some source files are picked up
through external headers during the build.


code:
CMAKE_DEPENDS_USE_COMPILER
--------------------------

.. versionadded:: 3.20

For the :ref:`Makefile Generators`, source dependencies are now, for a
selection of compilers, generated by the compiler itself. By defining this
variable with value ``FALSE``, you can restore the legacy behavior (i.e. using
CMake for dependencies discovery).


code:
CMAKE_DIRECTORY_LABELS
-----------------------

.. versionadded:: 3.10

Specify labels for the current directory.

This is used to initialize the :prop_dir:`LABELS` directory property.


code:
CMAKE_DISABLE_FIND_PACKAGE_<PackageName>
----------------------------------------

Variable for disabling :command:`find_package` calls.

Every non-``REQUIRED`` :command:`find_package` call in a project can be
disabled by setting the variable
``CMAKE_DISABLE_FIND_PACKAGE_<PackageName>`` to ``TRUE``.
This can be used to build a project without an optional package,
although that package is installed.

This switch should be used during the initial CMake run.  Otherwise if
the package has already been found in a previous CMake run, the
variables which have been stored in the cache will still be there.  In
that case it is recommended to remove the cache variables for this
package from the cache using the cache editor or :option:`cmake -U`.

Note that this variable can lead to inconsistent results within the project.
Consider the case where a dependency is requested via :command:`find_package`
from two different places within the project.  If the first call does not
have the ``REQUIRED`` keyword, it will not find the dependency when
``CMAKE_DISABLE_FIND_PACKAGE_<PackageName>`` is set to true for that
dependency.  The project will proceed under the assumption that the dependency
isn't available.  If the second call elsewhere in the project *does* have the
``REQUIRED`` keyword, it can succeed.  Two different parts of the same project
have then seen opposite results for the same dependency.

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


code:
CMAKE_DISABLE_PRECOMPILE_HEADERS
--------------------------------

.. versionadded:: 3.16

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

By default ``CMAKE_DISABLE_PRECOMPILE_HEADERS`` is ``OFF``.


code:
CMAKE_DLL_NAME_WITH_SOVERSION
-----------------------------

.. versionadded:: 3.27

This variable is used to initialize the :prop_tgt:`DLL_NAME_WITH_SOVERSION`
property on shared library targets for the Windows platform, which is selected
when the :variable:`WIN32` variable is set.

See this target property for additional information.

Please note that setting this variable has no effect if versioned filenames
are globally disabled with the :variable:`CMAKE_PLATFORM_NO_VERSIONED_SONAME`
variable.


code:
CMAKE_DL_LIBS
-------------

Name of library containing ``dlopen`` and ``dlclose``.

The name of the library that has ``dlopen`` and ``dlclose`` in it, usually
``-ldl`` on most UNIX machines.


code:
CMAKE_DOTNET_SDK
----------------

.. versionadded:: 3.23

Default value for :prop_tgt:`DOTNET_SDK` property of targets.

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


code:
CMAKE_DOTNET_TARGET_FRAMEWORK
-----------------------------

.. versionadded:: 3.17

Default value for :prop_tgt:`DOTNET_TARGET_FRAMEWORK` property	of
targets.

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

Setting ``CMAKE_DOTNET_TARGET_FRAMEWORK`` may be necessary
when working with ``C#`` and newer .NET framework versions to
avoid referencing errors with the ``ALL_BUILD`` CMake target.

This variable is only evaluated for :ref:`Visual Studio Generators`
VS 2010 and above.


code:
CMAKE_DOTNET_TARGET_FRAMEWORK_VERSION
-------------------------------------

.. versionadded:: 3.12

Default value for :prop_tgt:`DOTNET_TARGET_FRAMEWORK_VERSION`
property of targets.

This variable is used to initialize the
:prop_tgt:`DOTNET_TARGET_FRAMEWORK_VERSION` property on all
targets. See that target property for additional information. When set,
:variable:`CMAKE_DOTNET_TARGET_FRAMEWORK` takes precednece over this
variable. See that variable or the associated target property
:prop_tgt:`DOTNET_TARGET_FRAMEWORK` for additional information.

Setting ``CMAKE_DOTNET_TARGET_FRAMEWORK_VERSION`` may be necessary
when working with ``C#`` and newer .NET framework versions to
avoid referencing errors with the ``ALL_BUILD`` CMake target.

This variable is only evaluated for :ref:`Visual Studio Generators`
VS 2010 and above.


code:
CMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES
---------------------------------------

.. versionadded:: 3.6

This cache variable is used by the Eclipse project generator.  See
:manual:`cmake-generators(7)`.

The Eclipse project generator generates so-called linked resources
e.g. to the subproject root dirs in the source tree or to the source files
of targets.
This can be disabled by setting this variable to FALSE.


code:
CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT
-------------------------------------

.. versionadded:: 3.6

This cache variable is used by the Eclipse project generator.  See
:manual:`cmake-generators(7)`.

If this variable is set to TRUE, the Eclipse project generator will generate
an Eclipse project in :variable:`CMAKE_SOURCE_DIR` . This project can then
be used in Eclipse e.g. for the version control functionality.
``CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT`` defaults to ``FALSE``; so
nothing is written into the source directory.


code:
CMAKE_ECLIPSE_MAKE_ARGUMENTS
----------------------------

.. versionadded:: 3.6

This cache variable is used by the Eclipse project generator.  See
:manual:`cmake-generators(7)`.

This variable holds arguments which are used when Eclipse invokes the make
tool. By default it is initialized to hold flags to enable parallel builds
(using -j typically).


code:
CMAKE_ECLIPSE_RESOURCE_ENCODING
-------------------------------

.. versionadded:: 3.16

This cache variable tells the :generator:`Eclipse CDT4` project generator
to set the resource encoding to the given value in generated project files.
If no value is given, no encoding will be set.


code:
CMAKE_ECLIPSE_VERSION
---------------------

.. versionadded:: 3.6

This cache variable is used by the Eclipse project generator.  See
:manual:`cmake-generators(7)`.

When using the Eclipse project generator, CMake tries to find the Eclipse
executable and detect the version of it. Depending on the version it finds,
some features are enabled or disabled. If CMake doesn't find
Eclipse, it assumes the oldest supported version, Eclipse Callisto (3.2).


code:
CMAKE_EDIT_COMMAND
------------------

Full path to :manual:`cmake-gui(1)` or :manual:`ccmake(1)`.  Defined only for
:ref:`Makefile Generators` and :ref:`Ninja Generators` when not using any
:ref:`Extra Generators`.

This is the full path to the CMake executable that can graphically
edit the cache.  For example, :manual:`cmake-gui(1)` or :manual:`ccmake(1)`.


code:
CMAKE_ENABLE_EXPORTS
--------------------

.. versionadded:: 3.4

Specify whether executables export symbols for loadable modules.

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

This variable has been superseded by the
:variable:`CMAKE_EXECUTABLE_ENABLE_EXPORTS` variable.  It is provided for
backward compatibility with older CMake code, but should not be used in new
projects.


code:
CMAKE_ERROR_DEPRECATED
----------------------

Whether to issue errors for deprecated functionality.

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


code:
CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION
-------------------------------------------

Ask ``cmake_install.cmake`` script 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.  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 fatal error messages from the script.


code:
CMAKE_EXECUTABLE_ENABLE_EXPORTS
-------------------------------

.. versionadded:: 3.27

Specify whether executables export symbols for loadable modules.

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

This variable supersede the :variable:`CMAKE_ENABLE_EXPORTS` variable.


code:
CMAKE_EXECUTABLE_SUFFIX
-----------------------

The suffix for executables on this platform.

The suffix to use for the end of an executable filename if any, ``.exe``
on Windows.

:variable:`CMAKE_EXECUTABLE_SUFFIX_<LANG>` overrides this for
language ``<LANG>``.


code:
CMAKE_EXECUTABLE_SUFFIX_<LANG>
------------------------------

The suffix to use for the end of an executable filename of ``<LANG>``
compiler target architecture, if any.

It overrides :variable:`CMAKE_EXECUTABLE_SUFFIX` for language ``<LANG>``.


code:
CMAKE_EXECUTE_PROCESS_COMMAND_ECHO
----------------------------------

.. versionadded:: 3.15

If this variable is set to ``STDERR``, ``STDOUT`` or ``NONE`` then commands
in :command:`execute_process` calls will be printed to either stderr or
stdout or not at all.


code:
CMAKE_EXE_LINKER_FLAGS
----------------------

Linker flags to be used to create executables.

These flags will be used by the linker when creating an executable.


code:
CMAKE_EXE_LINKER_FLAGS_<CONFIG>
-------------------------------

Flags to be used when linking an executable.

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


code:
CMAKE_EXE_LINKER_FLAGS_<CONFIG>_INIT
------------------------------------

.. versionadded:: 3.7

Value used to initialize the :variable:`CMAKE_EXE_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_EXE_LINKER_FLAGS_INIT`.


code:
CMAKE_EXE_LINKER_FLAGS_INIT
---------------------------

.. versionadded:: 3.7

Value used to initialize the :variable:`CMAKE_EXE_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_EXE_LINKER_FLAGS_<CONFIG>_INIT`.


code:
CMAKE_EXPORT_COMPILE_COMMANDS
-----------------------------

.. versionadded:: 3.5

Enable/Disable output of compile commands during generation.

If enabled, generates a ``compile_commands.json`` file containing the exact
compiler calls for all translation units of the project in machine-readable
form.  The format of the JSON file looks like:

.. code-block:: javascript

  [
    {
      "directory": "/home/user/development/project",
      "command": "/usr/bin/c++ ... -c ../foo/foo.cc",
      "file": "../foo/foo.cc",
      "output": "../foo.dir/foo.cc.o"
    },

    ...

    {
      "directory": "/home/user/development/project",
      "command": "/usr/bin/c++ ... -c ../foo/bar.cc",
      "file": "../foo/bar.cc",
      "output": "../foo.dir/bar.cc.o"
    }
  ]

This is initialized by the :envvar:`CMAKE_EXPORT_COMPILE_COMMANDS` environment
variable, and initializes the :prop_tgt:`EXPORT_COMPILE_COMMANDS` target
property for all targets.

.. note::
  This option is implemented only by :ref:`Makefile Generators`
  and :ref:`Ninja Generators`.  It is ignored on other generators.

  This option currently does not work well in combination with
  the :prop_tgt:`UNITY_BUILD` target property or the
  :variable:`CMAKE_UNITY_BUILD` variable.


code:
CMAKE_EXPORT_FIND_PACKAGE_NAME
------------------------------

.. versionadded:: 3.29

Initializes the value of :prop_tgt:`EXPORT_FIND_PACKAGE_NAME`.


code:
CMAKE_EXPORT_NO_PACKAGE_REGISTRY
--------------------------------

.. versionadded:: 3.1

Disable the :command:`export(PACKAGE)` command when :policy:`CMP0090`
is not set to ``NEW``.

In some cases, for example for packaging and for system wide
installations, it is not desirable to write the user package registry.
If the ``CMAKE_EXPORT_NO_PACKAGE_REGISTRY`` variable is enabled,
the :command:`export(PACKAGE)` command will do nothing.

If :policy:`CMP0090` is set to ``NEW`` this variable does nothing, and the
:variable:`CMAKE_EXPORT_PACKAGE_REGISTRY` variable controls the behavior
instead.

See also :ref:`Disabling the Package Registry`.


code:
CMAKE_EXPORT_PACKAGE_REGISTRY
-----------------------------

.. versionadded:: 3.15

Enables the :command:`export(PACKAGE)` command when :policy:`CMP0090`
is set to ``NEW``.

The :command:`export(PACKAGE)` command does nothing by default.  In some cases
it is desirable to write to the user package registry, so the
``CMAKE_EXPORT_PACKAGE_REGISTRY`` variable may be set to enable it.

If :policy:`CMP0090` is *not* set to ``NEW`` this variable does nothing, and
the :variable:`CMAKE_EXPORT_NO_PACKAGE_REGISTRY` variable controls the behavior
instead.

See also :ref:`Disabling the Package Registry`.


code:
CMAKE_EXTRA_GENERATOR
---------------------

.. deprecated:: 3.27

  Support for :ref:`Extra Generators` is deprecated and will be removed from
  a future version of CMake.  IDEs may use the :manual:`cmake-file-api(7)`
  to view CMake-generated project build trees.

The extra generator used to build the project.  See
:manual:`cmake-generators(7)`.

When using the Eclipse, CodeBlocks, CodeLite, Kate or Sublime generators, CMake
generates Makefiles (:variable:`CMAKE_GENERATOR`) and additionally project
files for the respective IDE.  This IDE project file generator is stored in
``CMAKE_EXTRA_GENERATOR`` (e.g.  ``Eclipse CDT4``).


code:
CMAKE_EXTRA_SHARED_LIBRARY_SUFFIXES
-----------------------------------

Additional suffixes for shared libraries.

Extensions for shared libraries other than that specified by
:variable:`CMAKE_SHARED_LIBRARY_SUFFIX`, if any.  CMake uses this to recognize
external shared library files during analysis of libraries linked by a
target.


code:
CMAKE_FIND_APPBUNDLE
--------------------

.. versionadded:: 3.4

This variable affects how ``find_*`` commands choose between
macOS Application Bundles and unix-style package components.

On Darwin or systems supporting macOS Application Bundles, the
``CMAKE_FIND_APPBUNDLE`` variable can be set to empty or
one of the following:

``FIRST``
  Try to find application bundles before standard programs.
  This is the default on Darwin.

``LAST``
  Try to find application bundles after standard programs.

``ONLY``
  Only try to find application bundles.

``NEVER``
  Never try to find application bundles.


code:
CMAKE_FIND_DEBUG_MODE
---------------------

.. versionadded:: 3.17

Print extra find call information for the following commands to standard
error:

* :command:`find_program`
* :command:`find_library`
* :command:`find_file`
* :command:`find_path`
* :command:`find_package`

Output is designed for human consumption and not for parsing.
Enabling this variable is equivalent to using :option:`cmake --debug-find`
with the added ability to enable debugging for a subset of find calls.

.. code-block:: cmake

  set(CMAKE_FIND_DEBUG_MODE TRUE)
  find_program(...)
  set(CMAKE_FIND_DEBUG_MODE FALSE)

Default is unset.


code:
CMAKE_FIND_FRAMEWORK
--------------------

.. versionadded:: 3.4

This variable affects how ``find_*`` commands choose between
macOS Frameworks and unix-style package components.

On Darwin or systems supporting macOS Frameworks, the
``CMAKE_FIND_FRAMEWORK`` variable can be set to empty or
one of the following:

``FIRST``
  Try to find frameworks before standard libraries or headers.
  This is the default on Darwin.

``LAST``
  Try to find frameworks after standard libraries or headers.

``ONLY``
  Only try to find frameworks.

``NEVER``
  Never try to find frameworks.


code:
CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX
------------------------------------

.. versionadded:: 3.9

Specify a ``<suffix>`` to tell the :command:`find_library` command to
search in a ``lib<suffix>`` directory before each ``lib`` directory that
would normally be searched.

This overrides the behavior of related global properties:

* :prop_gbl:`FIND_LIBRARY_USE_LIB32_PATHS`
* :prop_gbl:`FIND_LIBRARY_USE_LIB64_PATHS`
* :prop_gbl:`FIND_LIBRARY_USE_LIBX32_PATHS`


code:
CMAKE_FIND_LIBRARY_PREFIXES
---------------------------

Prefixes to prepend when looking for libraries.

This specifies what prefixes to add to library names when the
:command:`find_library` command looks for libraries.  On UNIX systems this is
typically ``lib``, meaning that when trying to find the ``foo`` library it
will look for ``libfoo``.


code:
CMAKE_FIND_LIBRARY_SUFFIXES
---------------------------

Suffixes to append when looking for libraries.

This specifies what suffixes to add to library names when the
:command:`find_library` command looks for libraries.  On Windows systems this
is typically ``.lib`` and, depending on the compiler, ``.dll.lib``, ``.dll.a``,
``.a`` (e.g. rustc, GCC, or Clang), so when it tries to find the ``foo``
library, it will look for ``[<prefix>]foo[.dll].lib`` and/or
``[<prefix>]foo[.dll].a``, depending on the compiler used and the ``<prefix>``
specified in the :variable:`CMAKE_FIND_LIBRARY_PREFIXES`.


code:
CMAKE_FIND_NO_INSTALL_PREFIX
----------------------------

Exclude the values of the :variable:`CMAKE_INSTALL_PREFIX` and
:variable:`CMAKE_STAGING_PREFIX` variables from
:variable:`CMAKE_SYSTEM_PREFIX_PATH`.  CMake adds these project-destination
prefixes to :variable:`CMAKE_SYSTEM_PREFIX_PATH` by default in order to
support building a series of dependent packages and installing them into
a common prefix.  Set ``CMAKE_FIND_NO_INSTALL_PREFIX`` to ``TRUE``
to suppress this behavior.

The :variable:`CMAKE_SYSTEM_PREFIX_PATH` is initialized on the first call to a
:command:`project` or :command:`enable_language` command.  Therefore one must
set ``CMAKE_FIND_NO_INSTALL_PREFIX`` before this in order to take effect.  A
user may set the variable as a cache entry on the command line to achieve this.

Note that the prefix(es) may still be searched for other reasons, such as being
the same prefix as the CMake installation, or for being a built-in system
prefix.


code:
CMAKE_FIND_PACKAGE_NAME
-----------------------

.. versionadded:: 3.1.1

Defined by the :command:`find_package` command while loading
a find module to record the caller-specified package name.
See command documentation for details.


code:
CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY
--------------------------------------

.. versionadded:: 3.1

.. deprecated:: 3.16

  Use the :variable:`CMAKE_FIND_USE_PACKAGE_REGISTRY` variable instead.

By default this variable is not set. If neither
:variable:`CMAKE_FIND_USE_PACKAGE_REGISTRY` nor
``CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY`` is set, then
:command:`find_package()` will use the :ref:`User Package Registry`
unless the ``NO_CMAKE_PACKAGE_REGISTRY`` option is provided.

``CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY`` is ignored if
:variable:`CMAKE_FIND_USE_PACKAGE_REGISTRY` is set.

In some cases, for example to locate only system wide installations, it
is not desirable to use the :ref:`User Package Registry` when searching
for packages. If the ``CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY``
variable is ``TRUE``, all the :command:`find_package` commands will skip
the :ref:`User Package Registry` as if they were called with the
``NO_CMAKE_PACKAGE_REGISTRY`` argument.

See also :ref:`Disabling the Package Registry`.


code:
CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY
---------------------------------------------

.. versionadded:: 3.1

.. deprecated:: 3.16

  Use the :variable:`CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY` variable instead.

By default this variable is not set. If neither
:variable:`CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY` nor
``CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY`` is set, then
:command:`find_package()` will use the :ref:`System Package Registry`
unless the ``NO_CMAKE_SYSTEM_PACKAGE_REGISTRY`` option is provided.

``CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY`` is ignored if
:variable:`CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY` is set.

In some cases, it is not desirable to use the
:ref:`System Package Registry` when searching for packages. If the
``CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY`` variable is
``TRUE``, all the :command:`find_package` commands will skip
the :ref:`System Package Registry` as if they were called with the
``NO_CMAKE_SYSTEM_PACKAGE_REGISTRY`` argument.

See also :ref:`Disabling the Package Registry`.


code:
CMAKE_FIND_PACKAGE_PREFER_CONFIG
---------------------------------

.. versionadded:: 3.15

Tell :command:`find_package` to try "Config" mode before "Module" mode if no
mode was specified.

The command :command:`find_package` operates without an explicit mode when
the reduced signature is used without the ``MODULE`` option. In this case,
by default, CMake first tries Module mode by searching for a
``Find<pkg>.cmake`` module.  If it fails, CMake then searches for the package
using Config mode.

Set ``CMAKE_FIND_PACKAGE_PREFER_CONFIG`` to ``TRUE`` to tell
:command:`find_package` to first search using Config mode before falling back
to Module mode.

This variable may be useful when a developer has compiled a custom version of
a common library and wishes to link it to a dependent project.  If this
variable is set to ``TRUE``, it would prevent a dependent project's call
to :command:`find_package` from selecting the default library located by the
system's ``Find<pkg>.cmake`` module before finding the developer's custom
built library.

Once this variable is set, it is the responsibility of the exported
``<pkg>Config.cmake`` files to provide the same result variables as the
``Find<pkg>.cmake`` modules so that dependent projects can use them
interchangeably.


code:
CMAKE_FIND_PACKAGE_REDIRECTS_DIR
--------------------------------

.. versionadded:: 3.24

This read-only variable specifies a directory that the :command:`find_package`
command will check first before searching anywhere else for a module or config
package file.  A config package file in this directory will always be found in
preference to any other Find module file or config package file.

The primary purpose of this variable is to facilitate integration between
:command:`find_package` and :command:`FetchContent_MakeAvailable`.  The latter
command may create files in the ``CMAKE_FIND_PACKAGE_REDIRECTS_DIR`` directory
when it populates a dependency.  This allows subsequent calls to
:command:`find_package` for the same dependency to reuse the populated
contents instead of trying to satisfy the dependency from somewhere external
to the build.  Projects may also want to write files into this directory in
some situations (see :ref:`FetchContent-find_package-integration-examples`
for examples).

The directory that ``CMAKE_FIND_PACKAGE_REDIRECTS_DIR`` points to will always
be erased and recreated empty at the start of every CMake run.  Any files
written into this directory during the CMake run will be lost the next time
CMake configures the project.

``CMAKE_FIND_PACKAGE_REDIRECTS_DIR`` is only set in CMake project mode.
It is not set when CMake is run in script mode
(i.e. :option:`cmake -P`).


code:
CMAKE_FIND_PACKAGE_RESOLVE_SYMLINKS
-----------------------------------

.. versionadded:: 3.14

Set to ``TRUE`` to tell :command:`find_package` calls to resolve symbolic
links in the value of ``<PackageName>_DIR``.

This is helpful in use cases where the package search path points at a
proxy directory in which symlinks to the real package locations appear.
This is not enabled by default because there are also common use cases
in which the symlinks should be preserved.


code:
CMAKE_FIND_PACKAGE_SORT_DIRECTION
---------------------------------

.. versionadded:: 3.7

The sorting direction used by :variable:`CMAKE_FIND_PACKAGE_SORT_ORDER`.
It can assume one of the following values:

``DEC``
  Default.  Ordering is done in descending mode.
  The highest folder found will be tested first.

``ASC``
  Ordering is done in ascending mode.
  The lowest folder found will be tested first.

If :variable:`CMAKE_FIND_PACKAGE_SORT_ORDER` is not set or is set to ``NONE``
this variable has no effect.


code:
CMAKE_FIND_PACKAGE_SORT_ORDER
-----------------------------

.. versionadded:: 3.7

The default order for sorting packages found using :command:`find_package`.
It can assume one of the following values:

``NONE``
  Default.  No attempt is done to sort packages.
  The first valid package found will be selected.

``NAME``
  Sort packages lexicographically before selecting one.

``NATURAL``
  Sort packages using natural order (see ``strverscmp(3)`` manual),
  i.e. such that contiguous digits are compared as whole numbers.

Natural sorting can be employed to return the highest version when multiple
versions of the same library are found by :command:`find_package`.  For
example suppose that the following libraries have been found:

* libX-1.1.0
* libX-1.2.9
* libX-1.2.10

By setting ``NATURAL`` order we can select the one with the highest
version number ``libX-1.2.10``.

.. code-block:: cmake

  set(CMAKE_FIND_PACKAGE_SORT_ORDER NATURAL)
  find_package(libX CONFIG)

The sort direction can be controlled using the
:variable:`CMAKE_FIND_PACKAGE_SORT_DIRECTION` variable
(by default decrescent, e.g. lib-B will be tested before lib-A).


code:
CMAKE_FIND_PACKAGE_TARGETS_GLOBAL
---------------------------------

.. versionadded:: 3.24

Setting to ``TRUE`` promotes all :prop_tgt:`IMPORTED` targets discoverd
by :command:`find_package` to a ``GLOBAL`` scope.

Setting this to ``TRUE`` is akin to specifying ``GLOBAL``
as an argument to :command:`find_package`.
Default value is ``OFF``.


code:
CMAKE_FIND_PACKAGE_WARN_NO_MODULE
---------------------------------

Tell :command:`find_package` to warn if called without an explicit mode.

If :command:`find_package` is called without an explicit mode option
(``MODULE``, ``CONFIG``, or ``NO_MODULE``) and no ``Find<pkg>.cmake`` module
is in :variable:`CMAKE_MODULE_PATH` then CMake implicitly assumes that the
caller intends to search for a package configuration file.  If no package
configuration file is found then the wording of the failure message
must account for both the case that the package is really missing and
the case that the project has a bug and failed to provide the intended
Find module.  If instead the caller specifies an explicit mode option
then the failure message can be more specific.

Set ``CMAKE_FIND_PACKAGE_WARN_NO_MODULE`` to ``TRUE`` to tell
:command:`find_package` to warn when it implicitly assumes Config mode.  This
helps developers enforce use of an explicit mode in all calls to
:command:`find_package` within a project.

This variable has no effect if :variable:`CMAKE_FIND_PACKAGE_PREFER_CONFIG` is
set to ``TRUE``.


code:
CMAKE_FIND_ROOT_PATH
--------------------

:ref:`Semicolon-separated list <CMake Language Lists>` of root paths to search on the filesystem.

This variable is most useful when cross-compiling. CMake uses the paths in
this list as alternative roots to find filesystem items with
:command:`find_package`, :command:`find_library` etc.


code:
CMAKE_FIND_ROOT_PATH_MODE_INCLUDE
---------------------------------

.. |FIND_XXX| replace:: :command:`find_file` and :command:`find_path`

.. include:: CMAKE_FIND_ROOT_PATH_MODE_XXX.txt


code:
CMAKE_FIND_ROOT_PATH_MODE_LIBRARY
---------------------------------

.. |FIND_XXX| replace:: :command:`find_library`

.. include:: CMAKE_FIND_ROOT_PATH_MODE_XXX.txt


code:
CMAKE_FIND_ROOT_PATH_MODE_PACKAGE
---------------------------------

.. |FIND_XXX| replace:: :command:`find_package`

.. include:: CMAKE_FIND_ROOT_PATH_MODE_XXX.txt


code:
CMAKE_FIND_ROOT_PATH_MODE_PROGRAM
---------------------------------

.. |FIND_XXX| replace:: :command:`find_program`

.. include:: CMAKE_FIND_ROOT_PATH_MODE_XXX.txt


code:
This variable controls whether the :variable:`CMAKE_FIND_ROOT_PATH` and
:variable:`CMAKE_SYSROOT` are used by |FIND_XXX|.

If set to ``ONLY``, then only the roots in :variable:`CMAKE_FIND_ROOT_PATH`
will be searched. If set to ``NEVER``, then the roots in
:variable:`CMAKE_FIND_ROOT_PATH` will be ignored and only the host system
root will be used. If set to ``BOTH``, then the host system paths and the
paths in :variable:`CMAKE_FIND_ROOT_PATH` will be searched.


code:
CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH
-------------------------------------

.. versionadded:: 3.16

Controls the default behavior of the following commands for whether or not to
search paths provided by cmake-specific environment variables:

* :command:`find_program`
* :command:`find_library`
* :command:`find_file`
* :command:`find_path`
* :command:`find_package`

This is useful in cross-compiling environments.

By default this variable is not set, which is equivalent to it having
a value of ``TRUE``.  Explicit options given to the above commands
take precedence over this variable.

See also the :variable:`CMAKE_FIND_USE_CMAKE_PATH`,
:variable:`CMAKE_FIND_USE_CMAKE_SYSTEM_PATH`,
:variable:`CMAKE_FIND_USE_INSTALL_PREFIX`,
:variable:`CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH`,
:variable:`CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY`,
:variable:`CMAKE_FIND_USE_PACKAGE_REGISTRY`,
and :variable:`CMAKE_FIND_USE_PACKAGE_ROOT_PATH` variables.


code:
CMAKE_FIND_USE_CMAKE_PATH
-------------------------

.. versionadded:: 3.16

Controls the default behavior of the following commands for whether or not to
search paths provided by cmake-specific cache variables:

* :command:`find_program`
* :command:`find_library`
* :command:`find_file`
* :command:`find_path`
* :command:`find_package`

This is useful in cross-compiling environments.

By default this variable is not set, which is equivalent to it having
a value of ``TRUE``.  Explicit options given to the above commands
take precedence over this variable.

See also the :variable:`CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH`,
:variable:`CMAKE_FIND_USE_CMAKE_SYSTEM_PATH`,
:variable:`CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH`,
:variable:`CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY`,
:variable:`CMAKE_FIND_USE_PACKAGE_REGISTRY`,
and :variable:`CMAKE_FIND_USE_PACKAGE_ROOT_PATH` variables.


code:
CMAKE_FIND_USE_CMAKE_SYSTEM_PATH
--------------------------------

.. versionadded:: 3.16

Controls the default behavior of the following commands for whether or not to
search paths provided by platform-specific cmake variables:

* :command:`find_program`
* :command:`find_library`
* :command:`find_file`
* :command:`find_path`
* :command:`find_package`

This is useful in cross-compiling environments.

By default this variable is not set, which is equivalent to it having
a value of ``TRUE``.  Explicit options given to the above commands
take precedence over this variable.

See also the :variable:`CMAKE_FIND_USE_CMAKE_PATH`,
:variable:`CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH`,
:variable:`CMAKE_FIND_USE_INSTALL_PREFIX`,
:variable:`CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH`,
:variable:`CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY`,
:variable:`CMAKE_FIND_USE_PACKAGE_REGISTRY`,
and :variable:`CMAKE_FIND_USE_PACKAGE_ROOT_PATH` variables.


code:
CMAKE_FIND_USE_INSTALL_PREFIX
-----------------------------------

.. versionadded:: 3.24

Controls the default behavior of the following commands for whether or not to
search the locations in the :variable:`CMAKE_INSTALL_PREFIX` and
:variable:`CMAKE_STAGING_PREFIX` variables.

* :command:`find_program`
* :command:`find_library`
* :command:`find_file`
* :command:`find_path`
* :command:`find_package`

This is useful in cross-compiling environments.

Due to backwards compatibility with :variable:`CMAKE_FIND_NO_INSTALL_PREFIX`,
the behavior of the find command change based on if this variable exists.

============================== ============================ ===========
 CMAKE_FIND_USE_INSTALL_PREFIX CMAKE_FIND_NO_INSTALL_PREFIX   Search
============================== ============================ ===========
 Not Defined                      On                          NO
 Not Defined                      Off || Not Defined          YES
 Off                              On                          NO
 Off                              Off || Not Defined          NO
 On                               On                          YES
 On                               Off || Not Defined          YES
============================== ============================ ===========

By default this variable is not defined. Explicit options given to the above
commands take precedence over this variable.

See also the :variable:`CMAKE_FIND_USE_CMAKE_PATH`,
:variable:`CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH`,
:variable:`CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH`,
:variable:`CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY`,
:variable:`CMAKE_FIND_USE_PACKAGE_REGISTRY`,
and :variable:`CMAKE_FIND_USE_PACKAGE_ROOT_PATH` variables.


code:
CMAKE_FIND_USE_PACKAGE_REGISTRY
-------------------------------

.. versionadded:: 3.16

Controls the default behavior of the :command:`find_package` command for
whether or not to search paths provided by the :ref:`User Package Registry`.

By default this variable is not set and the behavior will fall back
to that determined by the deprecated
:variable:`CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY` variable.  If that is
also not set, then :command:`find_package` will use the
:ref:`User Package Registry` unless the ``NO_CMAKE_PACKAGE_REGISTRY`` option
is provided.

This variable takes precedence over
:variable:`CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY` when both are set.

In some cases, for example to locate only system wide installations, it
is not desirable to use the :ref:`User Package Registry` when searching
for packages.  If the ``CMAKE_FIND_USE_PACKAGE_REGISTRY``
variable is ``FALSE``, all the :command:`find_package` commands will skip
the :ref:`User Package Registry` as if they were called with the
``NO_CMAKE_PACKAGE_REGISTRY`` argument.

See also :ref:`Disabling the Package Registry` and the
:variable:`CMAKE_FIND_USE_CMAKE_PATH`,
:variable:`CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH`,
:variable:`CMAKE_FIND_USE_INSTALL_PREFIX`,
:variable:`CMAKE_FIND_USE_CMAKE_SYSTEM_PATH`,
:variable:`CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH`,
:variable:`CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY`,
and :variable:`CMAKE_FIND_USE_PACKAGE_ROOT_PATH` variables.


code:
CMAKE_FIND_USE_PACKAGE_ROOT_PATH
--------------------------------

.. versionadded:: 3.16

Controls the default behavior of the following commands for whether or not to
search paths provided by :variable:`<PackageName>_ROOT` variables:

* :command:`find_program`
* :command:`find_library`
* :command:`find_file`
* :command:`find_path`
* :command:`find_package`

By default this variable is not set, which is equivalent to it having
a value of ``TRUE``.  Explicit options given to the above commands
take precedence over this variable.

See also the :variable:`CMAKE_FIND_USE_CMAKE_PATH`,
:variable:`CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH`,
:variable:`CMAKE_FIND_USE_INSTALL_PREFIX`,
:variable:`CMAKE_FIND_USE_CMAKE_SYSTEM_PATH`,
:variable:`CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH`,
:variable:`CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY`,
and :variable:`CMAKE_FIND_USE_PACKAGE_REGISTRY` variables.


code:
CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH
--------------------------------------

.. versionadded:: 3.16

Controls the default behavior of the following commands for whether or not to
search paths provided by standard system environment variables:

* :command:`find_program`
* :command:`find_library`
* :command:`find_file`
* :command:`find_path`
* :command:`find_package`

This is useful in cross-compiling environments.

By default this variable is not set, which is equivalent to it having
a value of ``TRUE``.  Explicit options given to the above commands
take precedence over this variable.

See also the :variable:`CMAKE_FIND_USE_CMAKE_PATH`,
:variable:`CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH`,
:variable:`CMAKE_FIND_USE_INSTALL_PREFIX`,
:variable:`CMAKE_FIND_USE_CMAKE_SYSTEM_PATH`,
:variable:`CMAKE_FIND_USE_PACKAGE_REGISTRY`,
:variable:`CMAKE_FIND_USE_PACKAGE_ROOT_PATH`,
and :variable:`CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY` variables.


code:
CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY
--------------------------------------

.. versionadded:: 3.16

Controls searching the :ref:`System Package Registry` by the
:command:`find_package` command.

By default this variable is not set and the behavior will fall back
to that determined by the deprecated
:variable:`CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY` variable.
If that is also not set, then :command:`find_package()` will use the
:ref:`System Package Registry` unless the ``NO_CMAKE_SYSTEM_PACKAGE_REGISTRY``
option is provided.

This variable takes precedence over
:variable:`CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY` when both are set.

In some cases, for example to locate only user specific installations, it
is not desirable to use the :ref:`System Package Registry` when searching
for packages. If the ``CMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY``
variable is ``FALSE``, all the :command:`find_package` commands will skip
the :ref:`System Package Registry` as if they were called with the
``NO_CMAKE_SYSTEM_PACKAGE_REGISTRY`` argument.

See also :ref:`Disabling the Package Registry`.

See also the :variable:`CMAKE_FIND_USE_CMAKE_PATH`,
:variable:`CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH`,
:variable:`CMAKE_FIND_USE_INSTALL_PREFIX`,
:variable:`CMAKE_FIND_USE_CMAKE_SYSTEM_PATH`,
:variable:`CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH`,
:variable:`CMAKE_FIND_USE_PACKAGE_REGISTRY`,
and :variable:`CMAKE_FIND_USE_PACKAGE_ROOT_PATH` variables.


code:
CMAKE_FOLDER
------------

.. versionadded:: 3.12

Set the folder name. Use to organize targets in an IDE.

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


code:
CMAKE_FRAMEWORK
---------------

.. versionadded:: 3.15

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

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


code:
CMAKE_FRAMEWORK_MULTI_CONFIG_POSTFIX_<CONFIG>
---------------------------------------------

.. versionadded:: 3.18

Default framework filename postfix under configuration ``<CONFIG>`` when
using a multi-config generator.

When a framework target is created its :prop_tgt:`FRAMEWORK_MULTI_CONFIG_POSTFIX_<CONFIG>`
target property is initialized with the value of this variable if it is set.


code:
CMAKE_FRAMEWORK_PATH
--------------------

:ref:`Semicolon-separated list <CMake Language Lists>` of directories specifying a search path
for macOS frameworks used by the :command:`find_library`,
:command:`find_package`, :command:`find_path`, and :command:`find_file`
commands.

There is also an environment variable :envvar:`CMAKE_FRAMEWORK_PATH`, which is used
as an additional list of search directories.


code:
CMAKE_Fortran_FORMAT
--------------------

Set to ``FIXED`` or ``FREE`` to indicate the Fortran source layout.

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


code:
CMAKE_Fortran_MODDIR_DEFAULT
----------------------------

Fortran default module output directory.

Most Fortran compilers write ``.mod`` files to the current working
directory.  For those that do not, this is set to ``.`` and used when
the :prop_tgt:`Fortran_MODULE_DIRECTORY` target property is not set.


code:
CMAKE_Fortran_MODDIR_FLAG
-------------------------

Fortran flag for module output directory.

This stores the flag needed to pass the value of the
:prop_tgt:`Fortran_MODULE_DIRECTORY` target property to the compiler.


code:
CMAKE_Fortran_MODOUT_FLAG
-------------------------

Fortran flag to enable module output.

Most Fortran compilers write ``.mod`` files out by default.  For others,
this stores the flag needed to enable module output.


code:
CMAKE_Fortran_MODULE_DIRECTORY
------------------------------

Fortran module output directory.

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


code:
CMAKE_Fortran_PREPROCESS
------------------------

.. versionadded:: 3.18

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

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


code:
CMAKE_GENERATOR
---------------

The generator used to build the project.  See :manual:`cmake-generators(7)`.

The name of the generator that is being used to generate the build
files.  (e.g.  ``Unix Makefiles``, ``Ninja``, etc.)

The value of this variable should never be modified by project code.
A generator may be selected via the :option:`cmake -G` option,
interactively in :manual:`cmake-gui(1)`, or via the :envvar:`CMAKE_GENERATOR`
environment variable.


code:
CMAKE_GENERATOR_INSTANCE
------------------------

.. versionadded:: 3.11

Generator-specific instance specification provided by user.

Some CMake generators support selection of an instance of the native build
system when multiple instances are available.  If the user specifies an
instance (e.g. by setting this cache entry or via the
:envvar:`CMAKE_GENERATOR_INSTANCE` environment variable), or after a default
instance is chosen when a build tree is first configured, the value will be
available in this variable.

The value of this variable should never be modified by project code.
A toolchain file specified by the :variable:`CMAKE_TOOLCHAIN_FILE`
variable may initialize ``CMAKE_GENERATOR_INSTANCE`` as a cache entry.
Once a given build tree has been initialized with a particular value
for this variable, changing the value has undefined behavior.

Instance specification is supported only on specific generators.

Visual Studio Instance Selection
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

:ref:`Visual Studio Generators` support instance specification for
Visual Studio 2017 and above.  The ``CMAKE_GENERATOR_INSTANCE`` variable
may be set as a cache entry selecting an instance of Visual Studio
via one of the following forms:

* ``location``
* ``location[,key=value]*``
* ``key=value[,key=value]*``

The ``location`` specifies the absolute path to the top-level directory
of the VS installation.

The ``key=value`` pairs form a comma-separated list of options to
specify details of the instance selection.
Supported pairs are:

``version=<major>.<minor>.<date>.<build>``
  .. versionadded:: 3.23

  Specify the 4-component VS Build Version, a.k.a. Build Number.

  .. include:: CMAKE_VS_VERSION_BUILD_NUMBER_COMPONENTS.txt

.. versionadded:: 3.23

  A portable VS instance, which is not known to the Visual Studio Installer,
  may be specified by providing both ``location`` and ``version=``.

If the value of ``CMAKE_GENERATOR_INSTANCE`` is not specified explicitly
by the user or a toolchain file, CMake queries the Visual Studio Installer
to locate VS instances, chooses one, and sets the variable as a cache entry
to hold the value persistently.  If an environment variable of the form
``VS##0COMNTOOLS``, where ``##`` the Visual Studio major version number,
is set and points to the ``Common7/Tools`` directory within one of the
VS instances, that instance will be used.  Otherwise, if more than one
VS instance is installed we do not define which one is chosen by default.

The VS version build number of the selected VS instance is provided in
the :variable:`CMAKE_VS_VERSION_BUILD_NUMBER` variable.


code:
CMAKE_GENERATOR_PLATFORM
------------------------

.. versionadded:: 3.1

Generator-specific target platform specification provided by user.

Some CMake generators support a target platform name to be given
to the native build system to choose a compiler toolchain.
If the user specifies a platform name (e.g. via the :option:`cmake -A`
option or via the :envvar:`CMAKE_GENERATOR_PLATFORM` environment variable)
the value will be available in this variable.

The value of this variable should never be modified by project code.
A toolchain file specified by the :variable:`CMAKE_TOOLCHAIN_FILE`
variable may initialize ``CMAKE_GENERATOR_PLATFORM``.  Once a given
build tree has been initialized with a particular value for this
variable, changing the value has undefined behavior.

Platform specification is supported only on specific generators:

* For :ref:`Visual Studio Generators` with VS 2005 and above this
  specifies the target architecture.

* For :generator:`Green Hills MULTI` this specifies the target architecture.

See native build system documentation for allowed platform names.

.. _`Visual Studio Platform Selection`:

Visual Studio Platform Selection
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The :ref:`Visual Studio Generators` support platform specification
using one of these forms:

* ``platform``
* ``platform[,key=value]*``
* ``key=value[,key=value]*``

The ``platform`` specifies the target platform (VS target architecture),
such as ``x64``, ``ARM64``, or ``Win32``.  The selected platform
name is provided in the :variable:`CMAKE_VS_PLATFORM_NAME` variable.

The ``key=value`` pairs form a comma-separated list of options to
specify generator-specific details of the platform selection.
Supported pairs are:

``version=<version>``
  .. versionadded:: 3.27

  Specify the Windows SDK version to use.  This is supported by VS 2015 and
  above when targeting Windows or Windows Store.  CMake will set the
  :variable:`CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION` variable to the
  selected SDK version.

  The ``<version>`` may be one of:

  ``10.0``
    Specify that any 10.0 SDK version may be used, and let Visual Studio
    pick one.  This is supported by VS 2019 and above.

  ``10.0.<build>.<increment>``
    Specify the exact 4-component SDK version, e.g., ``10.0.19041.0``.
    The specified version of the SDK must be installed.  It may not exceed
    the value of :variable:`CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM`,
    if that variable is set.

  ``8.1``
    Specify the 8.1 SDK version.  This is always supported by VS 2015.
    On VS 2017 and above the 8.1 SDK must be installed.

  If the ``version`` field is not specified, CMake selects a version as
  described in the :variable:`CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION`
  variable documentation.


code:
CMAKE_GENERATOR_TOOLSET
-----------------------

Native build system toolset specification provided by user.

Some CMake generators support a toolset specification to tell the
native build system how to choose a compiler.  If the user specifies
a toolset (e.g. via the :option:`cmake -T` option or via
the :envvar:`CMAKE_GENERATOR_TOOLSET` environment variable) the value
will be available in this variable.

The value of this variable should never be modified by project code.
A toolchain file specified by the :variable:`CMAKE_TOOLCHAIN_FILE`
variable may initialize ``CMAKE_GENERATOR_TOOLSET``.  Once a given
build tree has been initialized with a particular value for this
variable, changing the value has undefined behavior.

Toolset specification is supported only on specific generators:

* :ref:`Visual Studio Generators` for VS 2010 and above
* The :generator:`Xcode` generator for Xcode 3.0 and above
* The :generator:`Green Hills MULTI` generator

See native build system documentation for allowed toolset names.

Visual Studio Toolset Selection
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The :ref:`Visual Studio Generators` support toolset specification
using one of these forms:

* ``toolset``
* ``toolset[,key=value]*``
* ``key=value[,key=value]*``

The ``toolset`` specifies the toolset name.  The selected toolset name
is provided in the :variable:`CMAKE_VS_PLATFORM_TOOLSET` variable.

The ``key=value`` pairs form a comma-separated list of options to
specify generator-specific details of the toolset selection.
Supported pairs are:

``cuda=<version>|<path>``
  Specify the CUDA toolkit version to use or the path to a
  standalone CUDA toolkit directory.  Supported by VS 2010
  and above. The version can only be used with the CUDA
  toolkit VS integration globally installed.
  See the :variable:`CMAKE_VS_PLATFORM_TOOLSET_CUDA` and
  :variable:`CMAKE_VS_PLATFORM_TOOLSET_CUDA_CUSTOM_DIR` variables.

``fortran=<compiler>``
  .. versionadded:: 3.29

  Specify the Fortran compiler to use, among those that integrate with VS.
  The value may be one of:

  ``ifort``
    Intel classic Fortran compiler.

  ``ifx``
    Intel oneAPI Fortran compiler.

  See the :variable:`CMAKE_VS_PLATFORM_TOOLSET_FORTRAN` variable.

``host=<arch>``
  Specify the host tools architecture as ``x64`` or ``x86``.
  Supported by VS 2013 and above.
  See the :variable:`CMAKE_VS_PLATFORM_TOOLSET_HOST_ARCHITECTURE`
  variable.

``version=<version>``
  Specify the toolset version to use.  Supported by VS 2017
  and above with the specified toolset installed.
  See the :variable:`CMAKE_VS_PLATFORM_TOOLSET_VERSION` variable.

``VCTargetsPath=<path>``
  Specify an alternative ``VCTargetsPath`` value for Visual Studio
  project files.  This allows use of VS platform extension configuration
  files (``.props`` and ``.targets``) that are not installed with VS.

Visual Studio Toolset Customization
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

**These are unstable interfaces with no compatibility guarantees**
because they hook into undocumented internal CMake implementation details.
Institutions may use these to internally maintain support for non-public
Visual Studio platforms and toolsets, but must accept responsibility to
make updates as changes are made to CMake.

Additional ``key=value`` pairs are available:

``customFlagTableDir=<path>``
  .. versionadded:: 3.21

  Specify the absolute path to a directory from which to load custom
  flag tables stored as JSON documents with file names of the form
  ``<platform>_<toolset>_<tool>.json`` or ``<platform>_<tool>.json``,
  where ``<platform>`` is the :variable:`CMAKE_VS_PLATFORM_NAME`,
  ``<toolset>`` is the :variable:`CMAKE_VS_PLATFORM_TOOLSET`,
  and ``<tool>`` is the tool for which the flag table is meant.
  **This naming pattern is an internal CMake implementation detail.**
  The ``<tool>`` names are undocumented.  The format of the ``.json``
  flag table files is undocumented.


code:
CMAKE_GHS_NO_SOURCE_GROUP_FILE
------------------------------

.. versionadded:: 3.14

``ON`` / ``OFF`` boolean to control if the project file for a target should
be one single file or multiple files.  Refer to
:prop_tgt:`GHS_NO_SOURCE_GROUP_FILE` for further details.


code:
CMAKE_GLOBAL_AUTOGEN_TARGET
---------------------------

.. versionadded:: 3.14

Switch to enable generation of a global ``autogen`` target.

When ``CMAKE_GLOBAL_AUTOGEN_TARGET`` is enabled, a custom target
``autogen`` is generated.  This target depends on all :prop_tgt:`AUTOMOC` and
:prop_tgt:`AUTOUIC` generated :ref:`<ORIGIN>_autogen` targets in the project.
By building the global ``autogen`` target, all :prop_tgt:`AUTOMOC` and
:prop_tgt:`AUTOUIC` files in the project will be generated.

The name of the global ``autogen`` target can be changed by setting
:variable:`CMAKE_GLOBAL_AUTOGEN_TARGET_NAME`.

By default ``CMAKE_GLOBAL_AUTOGEN_TARGET`` is unset.

See the :manual:`cmake-qt(7)` manual for more information on using CMake
with Qt.

.. note::

    :ref:`<ORIGIN>_autogen` targets by default inherit their origin target's
    dependencies. This might result in unintended dependency target builds when
    only :ref:`<ORIGIN>_autogen` targets are built.  A solution is to disable
    :prop_tgt:`AUTOGEN_ORIGIN_DEPENDS` on the respective origin targets.


code:
CMAKE_GLOBAL_AUTOGEN_TARGET_NAME
--------------------------------

.. versionadded:: 3.14

Change the name of the global ``autogen`` target.

When :variable:`CMAKE_GLOBAL_AUTOGEN_TARGET` is enabled, a global custom target
named ``autogen`` is created.  ``CMAKE_GLOBAL_AUTOGEN_TARGET_NAME``
allows to set a different name for that target.

By default ``CMAKE_GLOBAL_AUTOGEN_TARGET_NAME`` is unset.

See the :manual:`cmake-qt(7)` manual for more information on using CMake
with Qt.


code:
CMAKE_GLOBAL_AUTORCC_TARGET
---------------------------

.. versionadded:: 3.14

Switch to enable generation of a global ``autorcc`` target.

When ``CMAKE_GLOBAL_AUTORCC_TARGET`` is enabled, a custom target
``autorcc`` is generated. This target depends on all :prop_tgt:`AUTORCC`
generated ``<ORIGIN>_arcc_<QRC>`` targets in the project.
By building the global ``autorcc`` target, all :prop_tgt:`AUTORCC`
files in the project will be generated.

The name of the global ``autorcc`` target can be changed by setting
:variable:`CMAKE_GLOBAL_AUTORCC_TARGET_NAME`.

By default ``CMAKE_GLOBAL_AUTORCC_TARGET`` is unset.

See the :manual:`cmake-qt(7)` manual for more information on using CMake
with Qt.


code:
CMAKE_GLOBAL_AUTORCC_TARGET_NAME
--------------------------------

.. versionadded:: 3.14

Change the name of the global ``autorcc`` target.

When :variable:`CMAKE_GLOBAL_AUTORCC_TARGET` is enabled, a global custom target
named ``autorcc`` is created.  ``CMAKE_GLOBAL_AUTORCC_TARGET_NAME``
allows to set a different name for that target.

By default ``CMAKE_GLOBAL_AUTORCC_TARGET_NAME`` is unset.

See the :manual:`cmake-qt(7)` manual for more information on using CMake
with Qt.


code:
CMAKE_GNUtoMS
-------------

Convert GNU import libraries (``.dll.a``) to MS format (``.lib``).

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


code:
CMAKE_HIP_ARCHITECTURES
-----------------------

.. versionadded:: 3.21

List of GPU architectures to for which to generate device code.
Architecture names are interpreted based on :variable:`CMAKE_HIP_PLATFORM`.

This is initialized based on the value of :variable:`CMAKE_HIP_PLATFORM`:

``amd``
  Uses architectures reported by ``rocm_agent_enumerator``, if available,
  and otherwise to a default chosen by the compiler.

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


code:
CMAKE_HIP_EXTENSIONS
--------------------

.. versionadded:: 3.21

Default value for :prop_tgt:`HIP_EXTENSIONS` target property if set when a
target is created.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_HIP_PLATFORM
------------------

.. versionadded:: 3.28

GPU platform for which HIP language sources are to be compiled.

The value must be one of:

``amd``
  AMD GPUs

``nvidia``
  NVIDIA GPUs

If not specified, a default is computed via ``hipconfig --platform``.

:variable:`CMAKE_HIP_ARCHITECTURES` entries are interpreted with
as architectures of the GPU platform.

:variable:`CMAKE_HIP_COMPILER <CMAKE_<LANG>_COMPILER>` must target
the same GPU platform.


code:
CMAKE_HIP_STANDARD
------------------

.. versionadded:: 3.21

Default value for :prop_tgt:`HIP_STANDARD` target property if set when a target
is created.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_HIP_STANDARD_REQUIRED
---------------------------

.. versionadded:: 3.21

Default value for :prop_tgt:`HIP_STANDARD_REQUIRED` target property if set when
a target is created.

See the :manual:`cmake-compile-features(7)` manual for information on
compile features and a list of supported compilers.


code:
CMAKE_HOME_DIRECTORY
--------------------

Path to top of source tree. Same as :variable:`CMAKE_SOURCE_DIR`.

This is an internal cache entry used to locate the source directory
when loading a ``CMakeCache.txt`` from a build tree.  It should not
be used in project code.  The variable :variable:`CMAKE_SOURCE_DIR`
has the same value and should be preferred.


code:
CMAKE_HOST_APPLE
----------------

``True`` for Apple macOS operating systems.

Set to ``true`` when the host system is Apple macOS.


code:
CMAKE_HOST_BSD
--------------

.. versionadded:: 3.25

Set to a string value when the host system is BSD. This value can be one of
the following: DragonFlyBSD, FreeBSD, OpenBSD, or NetBSD.


code:
CMAKE_HOST_LINUX
----------------

.. versionadded:: 3.25

Set to true when the host system is Linux.


code:
CMAKE_HOST_SOLARIS
------------------

.. versionadded:: 3.6

``True`` for Oracle Solaris operating systems.

Set to ``true`` when the host system is Oracle Solaris.


code:
CMAKE_HOST_SYSTEM
-----------------

Composite Name of OS CMake is being run on.

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


code:
CMAKE_HOST_SYSTEM_NAME
----------------------

Name of the OS CMake is running on.

On systems that have the uname command, this variable is set to the
output of ``uname -s``.  ``Linux``, ``Windows``, and ``Darwin`` for macOS
are the values found on the big three operating systems.

For a list of possible values, see :variable:`CMAKE_SYSTEM_NAME`.


code:
CMAKE_HOST_SYSTEM_PROCESSOR
---------------------------

The name of the CPU CMake is running on.

Windows Platforms
^^^^^^^^^^^^^^^^^

On Windows, this variable is set to the value of the environment variable
``PROCESSOR_ARCHITECTURE``.

Unix Platforms
^^^^^^^^^^^^^^

On systems that support ``uname``, this variable is set to the output of:

- ``uname -m`` on GNU, Linux, Cygwin, Android, or
- ``arch`` on OpenBSD, or
- on other systems,

  * ``uname -p`` if its exit code is nonzero, or
  * ``uname -m`` otherwise.

macOS Platforms
^^^^^^^^^^^^^^^

The value of ``uname -m`` is used by default.

On Apple Silicon hosts, the architecture printed by ``uname -m`` may vary
based on CMake's own architecture and that of the invoking process tree.

.. versionadded:: 3.19.2

  On Apple Silicon hosts:

  * The :variable:`CMAKE_APPLE_SILICON_PROCESSOR` variable or
    the :envvar:`CMAKE_APPLE_SILICON_PROCESSOR` environment variable
    may be set to specify the host architecture explicitly.

  * If :variable:`CMAKE_OSX_ARCHITECTURES` is not set, CMake adds explicit
    flags to tell the compiler to build for the host architecture so the
    toolchain does not have to guess based on the process tree's architecture.


code:
CMAKE_HOST_SYSTEM_VERSION
-------------------------

The OS version CMake is running on.

A numeric version string for the system.  On systems that support
``uname``, this variable is set to the output of ``uname -r``. On other
systems this is set to major-minor version numbers.


code:
CMAKE_HOST_UNIX
---------------

``True`` for UNIX and UNIX like operating systems.

Set to ``true`` when the host system is UNIX or UNIX like (i.e.  APPLE and
CYGWIN).


code:
CMAKE_HOST_WIN32
----------------

``True`` if the host system is running Windows, including Windows 64-bit and MSYS.

Set to ``false`` on Cygwin.


code:
CMAKE_IGNORE_PATH
-----------------

.. |CMAKE_IGNORE_VAR| replace:: ``CMAKE_IGNORE_PATH``
.. |CMAKE_IGNORE_PREFIX_VAR| replace:: :variable:`CMAKE_IGNORE_PREFIX_PATH`

.. include:: IGNORE_SEARCH_PATH.txt
.. include:: IGNORE_SEARCH_LOCATIONS.txt
.. include:: IGNORE_SEARCH_NONSYSTEM.txt

See also the following variables:

- :variable:`CMAKE_IGNORE_PREFIX_PATH`
- :variable:`CMAKE_SYSTEM_IGNORE_PATH`
- :variable:`CMAKE_PREFIX_PATH`
- :variable:`CMAKE_LIBRARY_PATH`
- :variable:`CMAKE_INCLUDE_PATH`
- :variable:`CMAKE_PROGRAM_PATH`


code:
CMAKE_IGNORE_PREFIX_PATH
------------------------

.. versionadded:: 3.23

.. |CMAKE_IGNORE_VAR| replace:: ``CMAKE_IGNORE_PREFIX_PATH``
.. |CMAKE_IGNORE_NONPREFIX_VAR| replace:: :variable:`CMAKE_IGNORE_PATH`

.. include:: IGNORE_SEARCH_PREFIX.txt
.. include:: IGNORE_SEARCH_LOCATIONS.txt
.. include:: IGNORE_SEARCH_NONSYSTEM.txt

See also the following variables:

- :variable:`CMAKE_IGNORE_PATH`
- :variable:`CMAKE_SYSTEM_IGNORE_PREFIX_PATH`
- :variable:`CMAKE_PREFIX_PATH`
- :variable:`CMAKE_LIBRARY_PATH`
- :variable:`CMAKE_INCLUDE_PATH`
- :variable:`CMAKE_PROGRAM_PATH`


code:
CMAKE_IMPORT_LIBRARY_PREFIX
---------------------------

The prefix for import libraries that you link to.

The prefix to use for the name of an import library if used on this
platform.

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


code:
CMAKE_IMPORT_LIBRARY_SUFFIX
---------------------------

The suffix for import libraries that you link to.

The suffix to use for the end of an import library filename if used on
this platform.

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


code:
CMAKE_INCLUDE_CURRENT_DIR
-------------------------

Automatically add the current source and build directories to the include path.

If this variable is enabled, CMake automatically adds
:variable:`CMAKE_CURRENT_SOURCE_DIR` and :variable:`CMAKE_CURRENT_BINARY_DIR`
to the include path for each directory.  These additional include
directories do not propagate down to subdirectories.  This is useful
mainly for out-of-source builds, where files generated into the build
tree are included by files located in the source tree.

By default ``CMAKE_INCLUDE_CURRENT_DIR`` is ``OFF``.


code:
CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE
--------------------------------------

Automatically add the current source and build directories to the
:prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` target property.

If this variable is enabled, CMake automatically adds for each shared
library target, static library target, module target and executable
target, :variable:`CMAKE_CURRENT_SOURCE_DIR` and
:variable:`CMAKE_CURRENT_BINARY_DIR` to
the :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` target property.  By default
``CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE`` is ``OFF``.


code:
CMAKE_INCLUDE_DIRECTORIES_BEFORE
--------------------------------

Whether to append or prepend directories by default in
:command:`include_directories`.

This variable affects the default behavior of the :command:`include_directories`
command.  Setting this variable to ``ON`` is equivalent to using the ``BEFORE``
option in all uses of that command.


code:
CMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE
----------------------------------------

Whether to force prepending of project include directories.

This variable affects the order of include directories generated in compiler
command lines.  If set to ``ON``, it causes the :variable:`CMAKE_SOURCE_DIR`
and the :variable:`CMAKE_BINARY_DIR` to appear first.


code:
CMAKE_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 it
is empty, it is intended to be set by the project.

There is also an environment variable :envvar:`CMAKE_INCLUDE_PATH`, which is used
as an additional list of search directories.

See also :variable:`CMAKE_SYSTEM_INCLUDE_PATH` and :variable:`CMAKE_PREFIX_PATH`.


code:
CMAKE_INSTALL_DEFAULT_COMPONENT_NAME
------------------------------------

Default component used in :command:`install` commands.

If an :command:`install` command is used without the ``COMPONENT`` argument,
these files will be grouped into a default component.  The name of this
default install component will be taken from this variable.  It
defaults to ``Unspecified``.


code:
CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS
-------------------------------------------

.. versionadded:: 3.11

Default permissions for directories created implicitly during installation
of files by :command:`install` and :command:`file(INSTALL)`.

If ``make install`` is invoked and directories are implicitly created they
get permissions set by ``CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS``
variable or platform specific default permissions if the variable is not set.

Implicitly created directories are created if they are not explicitly installed
by :command:`install` command but are needed to install a file on a certain
path. Example of such locations are directories created due to the setting of
:variable:`CMAKE_INSTALL_PREFIX`.

Expected content of the ``CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS``
variable is a list of permissions that can be used by :command:`install` command
`PERMISSIONS` section.

Example usage:

::

 set(CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS
      OWNER_READ
      OWNER_WRITE
      OWNER_EXECUTE
      GROUP_READ
    )


code:
CMAKE_INSTALL_MESSAGE
---------------------

.. versionadded:: 3.1

Specify verbosity of installation script code generated by the
:command:`install` command (using the :command:`file(INSTALL)` command).
For paths that are newly installed or updated, installation
may print lines like::

  -- Installing: /some/destination/path

For paths that are already up to date, installation may print
lines like::

  -- Up-to-date: /some/destination/path

The ``CMAKE_INSTALL_MESSAGE`` variable may be set to control
which messages are printed:

``ALWAYS``
  Print both ``Installing`` and ``Up-to-date`` messages.

``LAZY``
  Print ``Installing`` but not ``Up-to-date`` messages.

``NEVER``
  Print neither ``Installing`` nor ``Up-to-date`` messages.

Other values have undefined behavior and may not be diagnosed.

If this variable is not set, the default behavior is ``ALWAYS``.


code:
CMAKE_INSTALL_NAME_DIR
----------------------

Directory name for installed targets on Apple platforms.

``CMAKE_INSTALL_NAME_DIR`` is used to initialize the
:prop_tgt:`INSTALL_NAME_DIR` property on all targets.  See that target
property for more information.


code:
CMAKE_INSTALL_PREFIX
--------------------

Install directory used by :command:`install`.

If ``make install`` is invoked or ``INSTALL`` is built, this directory is
prepended onto all install directories.

This variable defaults as follows:

* .. versionadded:: 3.29

    If the :envvar:`CMAKE_INSTALL_PREFIX` environment variable is set,
    its value is used as default for this variable.

* ``c:/Program Files/${PROJECT_NAME}`` on Windows.

* ``/usr/local`` on UNIX platforms.

See :variable:`CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT` for how a
project might choose its own default.

On UNIX one can use the ``DESTDIR`` mechanism in order to relocate the
whole installation to a staging area.  See the :envvar:`DESTDIR` environment
variable for more information.

The installation prefix is also added to :variable:`CMAKE_SYSTEM_PREFIX_PATH`
so that :command:`find_package`, :command:`find_program`,
:command:`find_library`, :command:`find_path`, and :command:`find_file`
will search the prefix for other software. This behavior can be disabled by
setting the :variable:`CMAKE_FIND_NO_INSTALL_PREFIX` to ``TRUE`` before the
first :command:`project` invocation.

.. note::

  Use the :module:`GNUInstallDirs` module to provide GNU-style
  options for the layout of directories within the installation.

The ``CMAKE_INSTALL_PREFIX`` may be defined when configuring a build tree
to set its installation prefix.  Or, when using the :manual:`cmake(1)`
command-line tool's :option:`--install <cmake --install>` mode, one may specify
a different prefix using the :option:`--prefix <cmake--install --prefix>`
option:

.. code-block:: shell

  cmake --install . --prefix /my/install/prefix


code:
CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT
-------------------------------------------

.. versionadded:: 3.7.1

CMake sets this variable to a ``TRUE`` value when the
:variable:`CMAKE_INSTALL_PREFIX` has just been initialized to
its default value, typically on the first
run of CMake within a new build tree and the :envvar:`CMAKE_INSTALL_PREFIX`
environment variable is not set on the first run of CMake. This can be used
by project code to change the default without overriding a user-provided value:

.. code-block:: cmake

  if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
    set(CMAKE_INSTALL_PREFIX "/my/default" CACHE PATH "..." FORCE)
  endif()


code:
CMAKE_INSTALL_REMOVE_ENVIRONMENT_RPATH
--------------------------------------

.. versionadded:: 3.16

Sets the default for whether toolchain-defined rpaths should be removed during
installation.

``CMAKE_INSTALL_REMOVE_ENVIRONMENT_RPATH`` is a boolean that provides the
default value for the :prop_tgt:`INSTALL_REMOVE_ENVIRONMENT_RPATH` property
of all subsequently created targets.


code:
CMAKE_INSTALL_RPATH
-------------------

The rpath to use for installed targets.

A semicolon-separated list specifying the rpath to use in installed
targets (for platforms that support it).  This is used to initialize
the target property :prop_tgt:`INSTALL_RPATH` for all targets.


code:
CMAKE_INSTALL_RPATH_USE_LINK_PATH
---------------------------------

Add paths to linker search and installed rpath.

``CMAKE_INSTALL_RPATH_USE_LINK_PATH`` is a boolean that if set to ``True``
will append to the runtime search path (rpath) of installed binaries
any directories outside the project that are in the linker search path or
contain linked library files.  The directories are appended after the
value of the :prop_tgt:`INSTALL_RPATH` target property.

This variable is used to initialize the target property
:prop_tgt:`INSTALL_RPATH_USE_LINK_PATH` for all targets.


code:
CMAKE_INTERNAL_PLATFORM_ABI
---------------------------

An internal variable subject to change.

This is used in determining the compiler ABI and is subject to change.


code:
CMAKE_INTERPROCEDURAL_OPTIMIZATION
----------------------------------

.. versionadded:: 3.9

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

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


code:
CMAKE_INTERPROCEDURAL_OPTIMIZATION_<CONFIG>
-------------------------------------------

.. versionadded:: 3.9

Default value for :prop_tgt:`INTERPROCEDURAL_OPTIMIZATION_<CONFIG>` of targets.

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


code:
CMAKE_IOS_INSTALL_COMBINED
--------------------------

.. versionadded:: 3.5
.. deprecated:: 3.28

  This is deprecated because :prop_tgt:`IOS_INSTALL_COMBINED` is deprecated.

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

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


code:
CMAKE_ISPC_HEADER_DIRECTORY
----------------------------

.. versionadded:: 3.19

ISPC generated header output directory.

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


code:
CMAKE_ISPC_HEADER_SUFFIX
------------------------

.. versionadded:: 3.19.2

Output suffix to be used for ISPC generated headers.

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


code:
CMAKE_ISPC_INSTRUCTION_SETS
---------------------------

.. versionadded:: 3.19

Default value for :prop_tgt:`ISPC_INSTRUCTION_SETS` property of targets.

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


code:
CMAKE_JOB_POOLS
---------------

.. versionadded:: 3.11

If the :prop_gbl:`JOB_POOLS` global property is not set, the value
of this variable is used in its place.  See :prop_gbl:`JOB_POOLS`
for additional information.


code:
CMAKE_JOB_POOL_COMPILE
----------------------

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


code:
CMAKE_JOB_POOL_LINK
-------------------

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


code:
CMAKE_JOB_POOL_PRECOMPILE_HEADER
--------------------------------

.. versionadded:: 3.17

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


code:
CMAKE_KATE_FILES_MODE
---------------------

.. versionadded:: 3.27

This cache variable is used by the Kate project generator and controls
to what mode the ``files`` entry in the project file will be set.  See
:manual:`cmake-generators(7)`.

Possible values are ``AUTO``, ``SVN``, ``GIT``, ``HG``, ``FOSSIL`` and ``LIST``.

When set to ``LIST``, CMake will put the list of source files known to CMake
in the project file.
When set to ``SVN``, ``GIT``, ``HG`` or ``FOSSIL``, CMake will set
the generated project accordingly to Subversion, git, Mercurial
or Fossil, and Kate will then use the respective command line tool to
retrieve the list of files in the project.
When unset or set to ``AUTO``, CMake will try to detect whether the
source directory is part of a git or svn checkout or not, and put the
respective entry into the project file.


code:
CMAKE_KATE_MAKE_ARGUMENTS
-------------------------

.. versionadded:: 3.0

This cache variable is used by the Kate project generator.  See
:manual:`cmake-generators(7)`.

This variable holds arguments which are used when Kate invokes the make
tool. By default it is initialized to hold flags to enable parallel builds
(using -j typically).


code:
CMAKE_<LANG>_ANDROID_TOOLCHAIN_MACHINE
--------------------------------------

.. versionadded:: 3.7.1

When :ref:`Cross Compiling for Android` this variable contains the
toolchain binutils machine name (e.g. ``gcc -dumpmachine``).  The
binutils typically have a ``<machine>-`` prefix on their name.

See also :variable:`CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX`
and :variable:`CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX`.


code:
CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX
-------------------------------------

.. versionadded:: 3.7

When :ref:`Cross Compiling for Android` this variable contains the absolute
path prefixing the toolchain GNU compiler and its binutils.

See also :variable:`CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX`
and :variable:`CMAKE_<LANG>_ANDROID_TOOLCHAIN_MACHINE`.

For example, the path to the linker is::

  ${CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX}ld${CMAKE_CXX_ANDROID_TOOLCHAIN_SUFFIX}


code:
CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX
-------------------------------------

.. versionadded:: 3.7

When :ref:`Cross Compiling for Android` this variable contains the
host platform suffix of the toolchain GNU compiler and its binutils.

See also :variable:`CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX`
and :variable:`CMAKE_<LANG>_ANDROID_TOOLCHAIN_MACHINE`.


code:
CMAKE_<LANG>_ARCHIVE_APPEND
---------------------------

Rule variable to append to a static archive.

This is a rule variable that tells CMake how to append to a static
archive.  It is used in place of :variable:`CMAKE_<LANG>_CREATE_STATIC_LIBRARY`
on some platforms in order to support large object counts.  See also
:variable:`CMAKE_<LANG>_ARCHIVE_CREATE` and
:variable:`CMAKE_<LANG>_ARCHIVE_FINISH`.