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.

repo_name: lazytadpole/codenamesilverfish

license: mit


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


code:
CMAKE_<LANG>_ARCHIVE_CREATE
---------------------------

Rule variable to create a new static archive.

This is a rule variable that tells CMake how to create 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_APPEND` and
:variable:`CMAKE_<LANG>_ARCHIVE_FINISH`.


code:
CMAKE_<LANG>_ARCHIVE_FINISH
---------------------------

Rule variable to finish an existing static archive.

This is a rule variable that tells CMake how to finish 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_APPEND`.


code:
CMAKE_<LANG>_BYTE_ORDER
-----------------------

.. versionadded:: 3.20

Byte order of ``<LANG>`` compiler target architecture, if known.
If defined and not empty, the value is one of:

``BIG_ENDIAN``
  The target architecture is Big Endian.

``LITTLE_ENDIAN``
  The target architecture is Little Endian.

This is defined for languages ``C``, ``CXX``, ``OBJC``, ``OBJCXX``,
and ``CUDA``.

If :variable:`CMAKE_OSX_ARCHITECTURES` specifies multiple architectures, the
value of ``CMAKE_<LANG>_BYTE_ORDER`` is non-empty only if all architectures
share the same byte order.


code:
CMAKE_<LANG>_CLANG_TIDY
-----------------------

.. versionadded:: 3.6

Default value for :prop_tgt:`<LANG>_CLANG_TIDY` target property
when ``<LANG>`` is ``C``, ``CXX``, ``OBJC`` or ``OBJCXX``.

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

.. code-block:: cmake

  set(CMAKE_CXX_CLANG_TIDY clang-tidy -checks=-*,readability-*)
  add_executable(foo foo.cxx)


code:
CMAKE_<LANG>_CLANG_TIDY_EXPORT_FIXES_DIR
----------------------------------------

.. versionadded:: 3.26

Default value for :prop_tgt:`<LANG>_CLANG_TIDY_EXPORT_FIXES_DIR` target
property when ``<LANG>`` is ``C``, ``CXX``, ``OBJC`` or ``OBJCXX``.

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

.. code-block:: cmake

  set(CMAKE_CXX_CLANG_TIDY_EXPORT_FIXES_DIR clang-tidy-fixes)
  add_executable(foo foo.cxx)


code:
CMAKE_<LANG>_COMPILER
---------------------

The full path to the compiler for ``LANG``.

This is the command that will be used as the ``<LANG>`` compiler.  Once
set, you can not change this variable.

Usage
^^^^^

This variable can be set by the user during the first time a build tree is configured.

If a non-full path value is supplied then CMake will resolve the full path of
the compiler.

The variable could be set in a user supplied toolchain file or via
:option:`-D <cmake -D>` on the command line.

.. note::
  Options that are required to make the compiler work correctly can be included
  as items in a list; they can not be changed.

.. code-block:: cmake

  #set within user supplied toolchain file
  set(CMAKE_C_COMPILER /full/path/to/qcc --arg1 --arg2)

or

.. code-block:: console

  $ cmake ... -DCMAKE_C_COMPILER='qcc;--arg1;--arg2'


code:
CMAKE_<LANG>_COMPILER_ABI
-------------------------

An internal variable subject to change.

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


code:
CMAKE_<LANG>_COMPILER_AR
------------------------

.. versionadded:: 3.9

A wrapper around ``ar`` adding the appropriate ``--plugin`` option for the
compiler.

See also :variable:`CMAKE_AR`.


code:
CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID
-------------------------------------

.. versionadded:: 3.10

An internal variable subject to change.

This is used to identify the variant of a compiler based on its target
architecture.  For some compilers this is needed to determine the correct
usage.


code:
CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN
----------------------------------------

The external toolchain for cross-compiling, if supported.

Some compiler toolchains do not ship their own auxiliary utilities such as
archivers and linkers.  The compiler driver may support a command-line argument
to specify the location of such tools.
``CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN`` may be set to a path to
the external toolchain and will be passed to the compiler driver if supported.

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


code:
CMAKE_<LANG>_COMPILER_FRONTEND_VARIANT
--------------------------------------

.. versionadded:: 3.14

Identification string of the compiler frontend variant.

Some compilers have multiple, different frontends for accepting command
line options.  (For example ``Clang`` originally only had a frontend
compatible with the ``GNU`` compiler but since its port to Windows
(``Clang-Cl``) it now also supports a frontend compatible with ``MSVC``.)
When CMake detects such a compiler it sets this
variable to what would have been the :variable:`CMAKE_<LANG>_COMPILER_ID` for
the compiler whose frontend it resembles.

.. note::
  In other words, this variable describes what command line options
  and language extensions the compiler frontend expects.

.. versionchanged:: 3.26
  This variable is set for ``GNU``, ``MSVC``, and ``AppleClang``
  compilers that have only one frontend variant.


code:
CMAKE_<LANG>_COMPILER_ID
------------------------

Compiler identification string.

A short string unique to the compiler vendor.  Possible values
include:

=============================== ===============================================
Value                           Name
=============================== ===============================================
``Absoft``                      Absoft Fortran
``ADSP``                        Analog VisualDSP++
``AppleClang``                  Apple Clang
``ARMCC``                       ARM Compiler
``ARMClang``                    ARM Compiler based on Clang
``Bruce``                       Bruce C Compiler
``CCur``                        Concurrent Fortran
``Clang``                       `LLVM Clang`_
``Cray``                        Cray Compiler
``CrayClang``                   Cray Clang-based Compiler
``Embarcadero``, ``Borland``    `Embarcadero`_
``Flang``                       `Classic Flang Fortran Compiler`_
``LLVMFlang``                   `LLVM Flang Fortran Compiler`_
``Fujitsu``                     Fujitsu HPC compiler (Trad mode)
``FujitsuClang``                Fujitsu HPC compiler (Clang mode)
``G95``                         `G95 Fortran`_
``GNU``                         `GNU Compiler Collection`_
``GHS``                         `Green Hills Software`_
``HP``                          Hewlett-Packard Compiler
``IAR``                         IAR Systems
``Intel``                       Intel Classic Compiler
``IntelLLVM``                   `Intel LLVM-Based Compiler`_
``LCC``                         MCST Elbrus C/C++/Fortran Compiler
``MSVC``                        `Microsoft Visual Studio`_
``NVHPC``                       `NVIDIA HPC Compiler`_
``NVIDIA``                      `NVIDIA CUDA Compiler`_
``OrangeC``                     `OrangeC Compiler`_
``OpenWatcom``                  `Open Watcom`_
``PGI``                         The Portland Group
``PathScale``                   PathScale
``SDCC``                        `Small Device C Compiler`_
``SunPro``                      Oracle Solaris Studio
``Tasking``                     `Tasking Compiler Toolsets`_
``TI``                          Texas Instruments
``TIClang``                     `Texas Instruments Clang-based Compilers`_
``TinyCC``                      `Tiny C Compiler`_
``XL``, ``VisualAge``, ``zOS``  IBM XL
``XLClang``                     IBM Clang-based XL
``IBMClang``                    IBM LLVM-based Compiler
=============================== ===============================================

This variable is not guaranteed to be defined for all compilers or
languages.

.. _LLVM Clang: https://clang.llvm.org
.. _Embarcadero: https://www.embarcadero.com
.. _Classic Flang Fortran Compiler: https://github.com/flang-compiler/flang
.. _LLVM Flang Fortran Compiler: https://github.com/llvm/llvm-project/tree/main/flang
.. _G95 Fortran: https://g95.sourceforge.net
.. _GNU Compiler Collection: https://gcc.gnu.org
.. _Green Hills Software: https://www.ghs.com/products/compiler.html
.. _Intel LLVM-Based Compiler:  https://www.intel.com/content/www/us/en/developer/tools/oneapi/overview.html
.. _Microsoft Visual Studio: https://visualstudio.microsoft.com
.. _NVIDIA HPC Compiler: https://developer.nvidia.com/hpc-compilers
.. _NVIDIA CUDA Compiler: https://developer.nvidia.com/cuda-llvm-compiler
.. _Open Watcom: https://open-watcom.github.io
.. _OrangeC Compiler: https://github.com/LADSoft/OrangeC
.. _Small Device C Compiler: https://sdcc.sourceforge.net
.. _Tiny C Compiler: https://bellard.org/tcc
.. _Tasking Compiler Toolsets: https://www.tasking.com
.. _Texas Instruments Clang-based Compilers: https://www.ti.com/tool/download/ARM-CGT-CLANG


code:
CMAKE_<LANG>_COMPILER_LAUNCHER
------------------------------

.. versionadded:: 3.4

Default value for :prop_tgt:`<LANG>_COMPILER_LAUNCHER` target property.
This variable is used to initialize the property on each target as it is
created.  This is done only when ``<LANG>`` is ``C``, ``CXX``, ``Fortran``,
``HIP``, ``ISPC``, ``OBJC``, ``OBJCXX``, or ``CUDA``.

This variable is initialized to the :envvar:`CMAKE_<LANG>_COMPILER_LAUNCHER`
environment variable if it is set.


code:
CMAKE_<LANG>_COMPILER_LINKER
----------------------------

.. versionadded:: 3.29

The full path to the linker for ``LANG``.

This is the command that will be used as the ``<LANG>`` linker.

This variable is not guaranteed to be defined for all linkers or languages.

.. note::
  This variable is read-only. It must not be set by the user. To select a
  specific linker, use the :variable:`CMAKE_LINKER_TYPE` variable or the
  :prop_tgt:`LINKER_TYPE` target property.


code:
CMAKE_<LANG>_COMPILER_LINKER_FRONTEND_VARIANT
---------------------------------------------

.. versionadded:: 3.29

Identification string of the linker frontend variant.

Some linkers have multiple, different frontends for accepting command
line options.  (For example ``LLCM LLD`` originally only had a frontend
compatible with the ``GNU`` compiler but since its port to Windows
(``lld-link``) it now also supports a frontend compatible with ``MSVC``.)
When CMake detects such a linker it sets this variable to what would have been
the :variable:`CMAKE_<LANG>_COMPILER_LINKER_ID` for the linker whose frontend
it resembles.

.. note::
  In other words, this variable describes what command line options
  and language extensions the linker frontend expects.

  This variable is set for ``GNU``, ``MSVC``, ``MOLD`` and ``AppleClang``
  linkers that have only one frontend variant.


code:
CMAKE_<LANG>_COMPILER_LINKER_ID
-------------------------------

.. versionadded:: 3.29

Linker identification string.

A short string unique to the linker vendor.  Possible values
include:

=============================== ===============================================
Value                           Name
=============================== ===============================================
``AppleClang``                  Apple Clang
``LLD``                         `LLVM LLD`_
``GNU``                         `GNU Binutils - ld linker`_ (also known as
                                ``bfd``)
``GNUgold``                     `GNU Binutils - gold linker`_
``MSVC``                        `Microsoft Visual Studio`_
``MOLD``                        `mold: A Modern Linker`_ or, on Apple, `sold`_
                                linker
``AIX``                         AIX system linker
``Solaris``                     SunOS system linker
=============================== ===============================================

This variable is not guaranteed to be defined for all linkers or languages.

.. _LLVM LLD: https://lld.llvm.org
.. _GNU Binutils - ld linker: https://sourceware.org/binutils
.. _GNU Binutils - gold linker: https://sourceware.org/binutils
.. _Microsoft Visual Studio: https://visualstudio.microsoft.com
.. _mold\: A Modern Linker: https://github.com/rui314/mold
.. _sold: https://github.com/bluewhalesystems/sold


code:
CMAKE_<LANG>_COMPILER_LINKER_VERSION
------------------------------------

.. versionadded:: 3.29

Linker version string.

Linker version in major[.minor[.patch[.tweak]]] format.  This
variable is not guaranteed to be defined for all linkers or
languages.


code:
CMAKE_<LANG>_COMPILER_LOADED
----------------------------

Defined to true if the language is enabled.

When language ``<LANG>`` is enabled by :command:`project` or
:command:`enable_language` this variable is defined to ``1``.


code:
CMAKE_<LANG>_COMPILER_PREDEFINES_COMMAND
----------------------------------------

.. versionadded:: 3.10

Command that outputs the compiler pre definitions.

See :prop_tgt:`AUTOMOC` which uses
:variable:`CMAKE_CXX_COMPILER_PREDEFINES_COMMAND <CMAKE_<LANG>_COMPILER_PREDEFINES_COMMAND>`
to generate the :prop_tgt:`AUTOMOC_COMPILER_PREDEFINES`.


code:
CMAKE_<LANG>_COMPILER_RANLIB
----------------------------

.. versionadded:: 3.9

A wrapper around ``ranlib`` adding the appropriate ``--plugin`` option for the
compiler.

See also :variable:`CMAKE_RANLIB`.


code:
CMAKE_<LANG>_COMPILER_TARGET
----------------------------

The target for cross-compiling, if supported.

Some compiler drivers are inherently cross-compilers, such as clang and
QNX qcc. These compiler drivers support a command-line argument to specify
the target to cross-compile for.

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


code:
CMAKE_<LANG>_COMPILER_VERSION
-----------------------------

Compiler version string.

Compiler version in major[.minor[.patch[.tweak]]] format.  This
variable is not guaranteed to be defined for all compilers or
languages.

For example ``CMAKE_C_COMPILER_VERSION`` and
``CMAKE_CXX_COMPILER_VERSION`` might indicate the respective C and C++
compiler version.


code:
CMAKE_<LANG>_COMPILER_VERSION_INTERNAL
--------------------------------------

.. versionadded:: 3.10

An internal variable subject to change.

This is used to identify the variant of a compiler based on an internal
version number.  For some compilers this is needed to determine the
correct usage.


code:
CMAKE_<LANG>_COMPILE_OBJECT
---------------------------

Rule variable to compile a single object file.

This is a rule variable that tells CMake how to compile a single
object file for the language ``<LANG>``.


code:
CMAKE_<LANG>_CPPCHECK
---------------------

.. versionadded:: 3.10

Default value for :prop_tgt:`<LANG>_CPPCHECK` target property. This variable
is used to initialize the property on each target as it is created.  This
is done only when ``<LANG>`` is ``C`` or ``CXX``.


code:
CMAKE_<LANG>_CPPLINT
--------------------

.. versionadded:: 3.8

Default value for :prop_tgt:`<LANG>_CPPLINT` target property. This variable
is used to initialize the property on each target as it is created.  This
is done only when ``<LANG>`` is ``C`` or ``CXX``.


code:
CMAKE_<LANG>_CREATE_SHARED_LIBRARY
----------------------------------

Rule variable to create a shared library.

This is a rule variable that tells CMake how to create a shared
library for the language ``<LANG>``.  This rule variable is a ``;`` delimited
list of commands to run to perform the linking step.


code:
CMAKE_<LANG>_CREATE_SHARED_MODULE
---------------------------------

Rule variable to create a shared module.

This is a rule variable that tells CMake how to create a shared
library for the language ``<LANG>``.  This rule variable is a ``;`` delimited
list of commands to run.


code:
CMAKE_<LANG>_CREATE_STATIC_LIBRARY
----------------------------------

Rule variable to create a static library.

This is a rule variable that tells CMake how to create a static
library for the language ``<LANG>``.


code:
CMAKE_<LANG>_EXTENSIONS
-----------------------

The variations are:

* :variable:`CMAKE_C_EXTENSIONS`
* :variable:`CMAKE_CXX_EXTENSIONS`
* :variable:`CMAKE_CUDA_EXTENSIONS`
* :variable:`CMAKE_HIP_EXTENSIONS`
* :variable:`CMAKE_OBJC_EXTENSIONS`
* :variable:`CMAKE_OBJCXX_EXTENSIONS`

Default values for :prop_tgt:`<LANG>_EXTENSIONS` target properties if set when
a target is created.  For the compiler's default setting see
:variable:`CMAKE_<LANG>_EXTENSIONS_DEFAULT`.

For supported CMake versions see the respective pages.

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


code:
CMAKE_<LANG>_EXTENSIONS_DEFAULT
-------------------------------

.. versionadded:: 3.22

Compiler's default extensions mode. Used as the default for the
:prop_tgt:`<LANG>_EXTENSIONS` target property when
:variable:`CMAKE_<LANG>_EXTENSIONS` is not set (see :policy:`CMP0128`).

This variable is read-only.  Modifying it is undefined behavior.


code:
CMAKE_<LANG>_FLAGS
------------------

Language-wide flags for language ``<LANG>`` used when building for
all configurations.  These flags will be passed to all invocations
of the compiler.  This includes invocations that drive compiling
and those that drive linking.

For each language, if this variable is not defined, it is initialized
and stored in the cache using values from environment variables in
combination with CMake's builtin defaults for the toolchain:

* ``CMAKE_C_FLAGS``:
  Initialized by the :envvar:`CFLAGS` environment variable.
* ``CMAKE_CXX_FLAGS``:
  Initialized by the :envvar:`CXXFLAGS` environment variable.
* ``CMAKE_CUDA_FLAGS``:
  Initialized by the :envvar:`CUDAFLAGS` environment variable.
* ``CMAKE_Fortran_FLAGS``:
  Initialized by the :envvar:`FFLAGS` environment variable.
* ``CMAKE_CSharp_FLAGS``:
  Initialized by the :envvar:`CSFLAGS` environment variable.
* ``CMAKE_HIP_FLAGS``:
  Initialized by the :envvar:`HIPFLAGS` environment variable.
* ``CMAKE_ISPC_FLAGS``:
  Initialized by the :envvar:`ISPCFLAGS` environment variable.

This value is a command-line string fragment. Therefore, multiple options
should be separated by spaces, and options with spaces should be quoted.

The flags in this variable will be passed before those in the
per-configuration :variable:`CMAKE_<LANG>_FLAGS_<CONFIG>` variable.
On invocations driving compiling, flags from both variables will be passed
before flags added by commands such as :command:`add_compile_options` and
:command:`target_compile_options`. On invocations driving linking,
they will be passed before flags added by commands such as
:command:`add_link_options` and :command:`target_link_options`.


code:
CMAKE_<LANG>_FLAGS_<CONFIG>
---------------------------

Language-wide flags for language ``<LANG>`` used when building for
the ``<CONFIG>`` configuration.  These flags will be passed to all
invocations of the compiler in the corresponding configuration.
This includes invocations that drive compiling and those that drive
linking.

The flags in this variable will be passed after those in the
:variable:`CMAKE_<LANG>_FLAGS` variable.  On invocations driving compiling,
flags from both variables will be passed before flags added by commands
such as :command:`add_compile_options` and :command:`target_compile_options`.
On invocations driving linking, they will be passed before flags added by
commands such as :command:`add_link_options` and
:command:`target_link_options`.


code:
CMAKE_<LANG>_FLAGS_<CONFIG>_INIT
--------------------------------

.. versionadded:: 3.11

Value used to initialize the :variable:`CMAKE_<LANG>_FLAGS_<CONFIG>` cache
entry the first time a build tree is configured for language ``<LANG>``.
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_<LANG>_FLAGS_INIT`.


code:
CMAKE_<LANG>_FLAGS_DEBUG
------------------------

This variable is the ``Debug`` variant of the
:variable:`CMAKE_<LANG>_FLAGS_<CONFIG>` variable.


code:
CMAKE_<LANG>_FLAGS_DEBUG_INIT
-----------------------------

.. versionadded:: 3.7

This variable is the ``Debug`` variant of the
:variable:`CMAKE_<LANG>_FLAGS_<CONFIG>_INIT` variable.


code:
CMAKE_<LANG>_FLAGS_INIT
-----------------------

.. versionadded:: 3.7

Value used to initialize the :variable:`CMAKE_<LANG>_FLAGS` cache entry
the first time a build tree is configured for language ``<LANG>``.
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.  For example,
the contents of a ``xxxFLAGS`` environment variable will be prepended,
where ``xxx`` will be language-specific but not necessarily the same as
``<LANG>`` (e.g. :envvar:`CXXFLAGS` for ``CXX``, :envvar:`FFLAGS` for
``Fortran``, and so on).
This value is a command-line string fragment. Therefore, multiple options
should be separated by spaces, and options with spaces should be quoted.

See also the configuration-specific
:variable:`CMAKE_<LANG>_FLAGS_<CONFIG>_INIT` variable.


code:
CMAKE_<LANG>_FLAGS_MINSIZEREL
-----------------------------

This variable is the ``MinSizeRel`` variant of the
:variable:`CMAKE_<LANG>_FLAGS_<CONFIG>` variable.


code:
CMAKE_<LANG>_FLAGS_MINSIZEREL_INIT
----------------------------------

.. versionadded:: 3.7

This variable is the ``MinSizeRel`` variant of the
:variable:`CMAKE_<LANG>_FLAGS_<CONFIG>_INIT` variable.


code:
CMAKE_<LANG>_FLAGS_RELEASE
--------------------------

This variable is the ``Release`` variant of the
:variable:`CMAKE_<LANG>_FLAGS_<CONFIG>` variable.


code:
CMAKE_<LANG>_FLAGS_RELEASE_INIT
-------------------------------

.. versionadded:: 3.7

This variable is the ``Release`` variant of the
:variable:`CMAKE_<LANG>_FLAGS_<CONFIG>_INIT` variable.


code:
CMAKE_<LANG>_FLAGS_RELWITHDEBINFO
---------------------------------

This variable is the ``RelWithDebInfo`` variant of the
:variable:`CMAKE_<LANG>_FLAGS_<CONFIG>` variable.


code:
CMAKE_<LANG>_FLAGS_RELWITHDEBINFO_INIT
--------------------------------------

.. versionadded:: 3.7

This variable is the ``RelWithDebInfo`` variant of the
:variable:`CMAKE_<LANG>_FLAGS_<CONFIG>_INIT` variable.


code:
CMAKE_<LANG>_HOST_COMPILER
--------------------------

.. versionadded:: 3.10
  ``CMAKE_CUDA_HOST_COMPILER``

.. versionadded:: 3.28
  ``CMAKE_HIP_HOST_COMPILER``

This variable is available when ``<LANG>`` is ``CUDA`` or ``HIP``.

When :variable:`CMAKE_<LANG>_COMPILER_ID` is
``NVIDIA``, ``CMAKE_<LANG>_HOST_COMPILER`` selects the compiler executable
to use when compiling host code for ``CUDA`` or ``HIP`` language files.
This maps to the ``nvcc -ccbin`` option.

The ``CMAKE_<LANG>_HOST_COMPILER`` variable may be set explicitly before CUDA
or HIP is first enabled by a :command:`project` or :command:`enable_language`
command.
This can be done via ``-DCMAKE_<LANG>_HOST_COMPILER=...`` on the command line
or in a :ref:`toolchain file <Cross Compiling Toolchain>`.  Or, one may set
the :envvar:`CUDAHOSTCXX` or :envvar:`HIPHOSTCXX` environment variable to
provide a default value.

Once the CUDA or HIP language is enabled, the ``CMAKE_<LANG>_HOST_COMPILER``
variable is read-only and changes to it are undefined behavior.

.. note::

  Since ``CMAKE_<LANG>_HOST_COMPILER`` is meaningful only when the
  :variable:`CMAKE_<LANG>_COMPILER_ID` is ``NVIDIA``,
  it does not make sense to set ``CMAKE_<LANG>_HOST_COMPILER`` without also
  setting ``CMAKE_<LANG>_COMPILER`` to NVCC.

.. note::

  Projects should not try to set ``CMAKE_<LANG>_HOST_COMPILER`` to match
  :variable:`CMAKE_CXX_COMPILER <CMAKE_<LANG>_COMPILER>` themselves.
  It is the end-user's responsibility, not the project's, to ensure that
  NVCC targets the same ABI as the C++ compiler.

.. note::

  Ignored when using :ref:`Visual Studio Generators`.


code:
CMAKE_<LANG>_IGNORE_EXTENSIONS
------------------------------

File extensions that should be ignored by the build.

This is a list of file extensions that may be part of a project for a
given language but are not compiled.


code:
CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES
-----------------------------------------

Directories implicitly searched by the compiler for header files.

CMake does not explicitly specify these directories on compiler
command lines for language ``<LANG>``.  This prevents system include
directories from being treated as user include directories on some
compilers, which is important for ``C``, ``CXX``, and ``CUDA`` to
avoid overriding standard library headers.

This value is not used for ``Fortran`` because it has no standard
library headers and some compilers do not search their implicit
include directories for module ``.mod`` files.


code:
CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES
--------------------------------------

Implicit linker search path detected for language ``<LANG>``.

Compilers typically pass directories containing language runtime
libraries and default library search paths when they invoke a linker.
These paths are implicit linker search directories for the compiler's
language.

For each language enabled by the :command:`project` or
:command:`enable_language` command, CMake automatically detects these
directories and reports the results in this variable.
The :envvar:`CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES_EXCLUDE` environment
variable may be set to exclude specific directories from the automatically
detected results.

When linking to a static library, CMake adds the implicit link directories
from this variable for each language used in the static library (except
the language whose compiler is used to drive linking).  In the case of an
imported static library, the :prop_tgt:`IMPORTED_LINK_INTERFACE_LANGUAGES`
target property lists the languages whose implicit link information is
needed.  If any of the languages is not enabled, its value for the
``CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES`` variable may instead be provided
by the project.  Or, a :variable:`toolchain file <CMAKE_TOOLCHAIN_FILE>`
may set the variable to a value known for the specified toolchain.  It will
either be overridden when the language is enabled, or used as a fallback.

Some toolchains read implicit directories from an environment variable such as
``LIBRARY_PATH``.  If using such an environment variable, keep its value
consistent when operating in a given build tree because CMake saves the value
detected when first creating a build tree.

If policy :policy:`CMP0060` is not set to ``NEW``, then when a library in one
of these directories is given by full path to :command:`target_link_libraries`
CMake will generate the ``-l<name>`` form on link lines for historical
purposes.

See also the :variable:`CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES` variable.


code:
CMAKE_<LANG>_IMPLICIT_LINK_FRAMEWORK_DIRECTORIES
------------------------------------------------

Implicit linker framework search path detected for language ``<LANG>``.

These paths are implicit linker framework search directories for the
compiler's language.  CMake automatically detects these directories
for each language and reports the results in this variable.


code:
CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES
------------------------------------

Implicit link libraries and flags detected for language ``<LANG>``.

Compilers typically pass language runtime library names and other
flags when they invoke a linker.  These flags are implicit link
options for the compiler's language.  For each language enabled
by the :command:`project` or :command:`enable_language` command,
CMake automatically detects these libraries and flags and reports
the results in this variable.

When linking to a static library, CMake adds the implicit link libraries and
flags from this variable for each language used in the static library (except
the language whose compiler is used to drive linking).  In the case of an
imported static library, the :prop_tgt:`IMPORTED_LINK_INTERFACE_LANGUAGES`
target property lists the languages whose implicit link information is
needed.  If any of the languages is not enabled, its value for the
``CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES`` variable may instead be provided
by the project.  Or, a :variable:`toolchain file <CMAKE_TOOLCHAIN_FILE>`
may set the variable to a value known for the specified toolchain.  It will
either be overridden when the language is enabled, or used as a fallback.

See also the :variable:`CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES` variable.


code:
CMAKE_<LANG>_INCLUDE_WHAT_YOU_USE
---------------------------------

.. versionadded:: 3.3

Default value for :prop_tgt:`<LANG>_INCLUDE_WHAT_YOU_USE` target property.
This variable is used to initialize the property on each target as it is
created.  This is done only when ``<LANG>`` is ``C`` or ``CXX``.


code:
CMAKE_<LANG>_LIBRARY_ARCHITECTURE
---------------------------------

Target architecture library directory name detected for ``<LANG>``.

If the ``<LANG>`` compiler passes to the linker an architecture-specific
system library search directory such as ``<prefix>/lib/<arch>`` this
variable contains the ``<arch>`` name if/as detected by CMake.


code:
CMAKE_<LANG>_LINKER_LAUNCHER
----------------------------

.. versionadded:: 3.21

Default value for :prop_tgt:`<LANG>_LINKER_LAUNCHER` target property. This
variable is used to initialize the property on each target as it is created.
This is done only when ``<LANG>`` is ``C``, ``CXX``, ``OBJC``, or ``OBJCXX``.

This variable is initialized to the :envvar:`CMAKE_<LANG>_LINKER_LAUNCHER`
environment variable if it is set.


code:
CMAKE_<LANG>_LINKER_PREFERENCE
------------------------------

An internal variable subject to change.

Preference value for linker language selection.

The "linker language" for executable, shared library, and module
targets is the language whose compiler will invoke the linker.  The
:prop_tgt:`LINKER_LANGUAGE` target property sets the language explicitly.
Otherwise, the linker language is that whose linker preference value
is highest among languages compiled and linked into the target.  See
also the :variable:`CMAKE_<LANG>_LINKER_PREFERENCE_PROPAGATES` variable.


code:
CMAKE_<LANG>_LINKER_PREFERENCE_PROPAGATES
-----------------------------------------

An internal variable subject to change.

True if :variable:`CMAKE_<LANG>_LINKER_PREFERENCE` propagates across targets.

This is used when CMake selects a linker language for a target.
Languages compiled directly into the target are always considered.  A
language compiled into static libraries linked by the target is
considered if this variable is true.


code:
CMAKE_<LANG>_LINKER_WRAPPER_FLAG
--------------------------------

.. versionadded:: 3.13

Defines the syntax of compiler driver option to pass options to the linker
tool. It will be used to translate the ``LINKER:`` prefix in the link options
(see :command:`add_link_options` and :command:`target_link_options`).

This variable holds a :ref:`semicolon-separated list <CMake Language Lists>` of tokens.
If a space (i.e. " ") is specified as last token, flag and ``LINKER:``
arguments will be specified as separate arguments to the compiler driver.
The :variable:`CMAKE_<LANG>_LINKER_WRAPPER_FLAG_SEP` variable can be specified
to manage concatenation of arguments.

For example, for ``Clang`` we have:

.. code-block:: cmake

  set (CMAKE_C_LINKER_WRAPPER_FLAG "-Xlinker" " ")

Specifying ``"LINKER:-z,defs"`` will be transformed in
``-Xlinker -z -Xlinker defs``.

For ``GNU GCC``:

.. code-block:: cmake

  set (CMAKE_C_LINKER_WRAPPER_FLAG "-Wl,")
  set (CMAKE_C_LINKER_WRAPPER_FLAG_SEP ",")

Specifying ``"LINKER:-z,defs"`` will be transformed in ``-Wl,-z,defs``.

And for ``SunPro``:

.. code-block:: cmake

  set (CMAKE_C_LINKER_WRAPPER_FLAG "-Qoption" "ld" " ")
  set (CMAKE_C_LINKER_WRAPPER_FLAG_SEP ",")

Specifying ``"LINKER:-z,defs"`` will be transformed in ``-Qoption ld -z,defs``.


code:
CMAKE_<LANG>_LINKER_WRAPPER_FLAG_SEP
------------------------------------

.. versionadded:: 3.13

This variable is used with :variable:`CMAKE_<LANG>_LINKER_WRAPPER_FLAG`
variable to format ``LINKER:`` prefix in the link options
(see :command:`add_link_options` and :command:`target_link_options`).

When specified, arguments of the ``LINKER:`` prefix will be concatenated using
this value as separator.


code:
CMAKE_<LANG>_LINK_EXECUTABLE
----------------------------

Rule variable to link an executable.

Rule variable to link an executable for the given language.


code:
CMAKE_<LANG>_LINK_GROUP_USING_<FEATURE>
---------------------------------------

.. versionadded:: 3.24

This variable defines how to link a group of libraries for the specified
``<FEATURE>`` when a :genex:`LINK_GROUP` generator expression is used and
the link language for the target is ``<LANG>``.
For this variable to have any effect, the associated
:variable:`CMAKE_<LANG>_LINK_GROUP_USING_<FEATURE>_SUPPORTED` variable
must be set to true.

The :variable:`CMAKE_LINK_GROUP_USING_<FEATURE>` variable should be defined
instead for features that are independent of the link language.

.. include:: CMAKE_LINK_GROUP_USING_FEATURE.txt