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

repo_name: lazytadpole/codenamesilverfish

license: mit


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


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

.. versionadded:: 3.24

This variable specifies whether the ``<FEATURE>`` is supported for the link
language ``<LANG>``.  If this variable is true, then the ``<FEATURE>`` must
be defined by :variable:`CMAKE_<LANG>_LINK_GROUP_USING_<FEATURE>`, and the
more generic :variable:`CMAKE_LINK_GROUP_USING_<FEATURE>_SUPPORTED` and
:variable:`CMAKE_LINK_GROUP_USING_<FEATURE>` variables are not used.

If ``CMAKE_<LANG>_LINK_GROUP_USING_<FEATURE>_SUPPORTED`` is false or is not
set, then the :variable:`CMAKE_LINK_GROUP_USING_<FEATURE>_SUPPORTED` variable
will determine whether ``<FEATURE>`` is deemed to be supported.


code:
CMAKE_<LANG>_LINK_LIBRARY_FILE_FLAG
-----------------------------------

.. versionadded:: 3.16

Language-specific flag to be used to link a library specified by
a path to its file.

The flag will be used before a library file path is given to the
linker.  This is needed only on very few platforms.


code:
CMAKE_<LANG>_LINK_LIBRARY_FLAG
------------------------------

.. versionadded:: 3.16

Flag to be used to link a library into a shared library or executable.

This flag will be used to specify a library to link to a shared library or an
executable for the specific language.  On most compilers this is ``-l``.


code:
CMAKE_<LANG>_LINK_LIBRARY_SUFFIX
--------------------------------

.. versionadded:: 3.16

Language-specific suffix for libraries that you link to.

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


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

.. versionadded:: 3.24

This variable defines how to link a library or framework for the specified
``<FEATURE>`` when a :genex:`LINK_LIBRARY` 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_LIBRARY_USING_<FEATURE>_SUPPORTED` variable
must be set to true.

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

.. include:: CMAKE_LINK_LIBRARY_USING_FEATURE.txt


code:
CMAKE_<LANG>_LINK_LIBRARY_USING_<FEATURE>_SUPPORTED
---------------------------------------------------

.. versionadded:: 3.24

Set to ``TRUE`` if the ``<FEATURE>``, as defined by variable
:variable:`CMAKE_<LANG>_LINK_LIBRARY_USING_<FEATURE>`, is supported for the
linker language ``<LANG>``.

.. note::

  This variable is evaluated before the more generic variable
  :variable:`CMAKE_LINK_LIBRARY_USING_<FEATURE>_SUPPORTED`.


code:
CMAKE_<LANG>_LINK_WHAT_YOU_USE_FLAG
-----------------------------------

.. versionadded:: 3.22

Linker flag to be used to configure linker so that all specified libraries on
the command line will be linked into the target.

See also variable :variable:`CMAKE_LINK_WHAT_YOU_USE_CHECK`.


code:
CMAKE_<LANG>_OUTPUT_EXTENSION
-----------------------------

Extension for the output of a compile for a single file.

This is the extension for an object file for the given ``<LANG>``.  For
example ``.obj`` for C on Windows.


code:
CMAKE_<LANG>_PLATFORM_ID
------------------------

An internal variable subject to change.

This is used in determining the platform and is subject to change.


code:
CMAKE_<LANG>_SIMULATE_ID
------------------------

Identification string of the "simulated" compiler.

Some compilers simulate other compilers to serve as drop-in
replacements.  When CMake detects such a compiler it sets this
variable to what would have been the :variable:`CMAKE_<LANG>_COMPILER_ID` for
the simulated compiler.

.. note::
  In other words, this variable describes the ABI compatibility
  of the generated code.


code:
CMAKE_<LANG>_SIMULATE_VERSION
-----------------------------

Version string of "simulated" compiler.

Some compilers simulate other compilers to serve as drop-in
replacements.  When CMake detects such a compiler it sets this
variable to what would have been the :variable:`CMAKE_<LANG>_COMPILER_VERSION`
for the simulated compiler.


code:
CMAKE_<LANG>_SIZEOF_DATA_PTR
----------------------------

Size of pointer-to-data types for language ``<LANG>``.

This holds the size (in bytes) of pointer-to-data types in the target
platform ABI.  It is defined for languages ``C`` and ``CXX`` (C++).


code:
CMAKE_<LANG>_SOURCE_FILE_EXTENSIONS
-----------------------------------

Extensions of source files for the given language.

This is the list of extensions for a given language's source files.


code:
CMAKE_<LANG>_STANDARD
---------------------

The variations are:

* :variable:`CMAKE_C_STANDARD`
* :variable:`CMAKE_CXX_STANDARD`
* :variable:`CMAKE_CUDA_STANDARD`
* :variable:`CMAKE_HIP_STANDARD`
* :variable:`CMAKE_OBJC_STANDARD`
* :variable:`CMAKE_OBJCXX_STANDARD`

Default values for :prop_tgt:`<LANG>_STANDARD` target properties if set when a
target is created.

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

.. versionadded:: 3.9

The compiler's default standard for the language ``<LANG>``. Empty if the
compiler has no conception of standard levels.


code:
CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES
-----------------------------------------

.. versionadded:: 3.6

Include directories to be used for every source file compiled with
the ``<LANG>`` compiler.  This is meant for specification of system
include directories needed by the language for the current platform.
The directories always appear at the end of the include path passed
to the compiler.

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

See also :variable:`CMAKE_<LANG>_STANDARD_LIBRARIES`.


code:
CMAKE_<LANG>_STANDARD_LIBRARIES
-------------------------------

.. versionadded:: 3.6

Libraries linked into every executable and shared library linked
for language ``<LANG>``.  This is meant for specification of system
libraries needed by the language for the current platform.

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

See also :variable:`CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES`.


code:
CMAKE_<LANG>_STANDARD_REQUIRED
------------------------------

The variations are:

* :variable:`CMAKE_C_STANDARD_REQUIRED`
* :variable:`CMAKE_CXX_STANDARD_REQUIRED`
* :variable:`CMAKE_CUDA_STANDARD_REQUIRED`
* :variable:`CMAKE_HIP_STANDARD_REQUIRED`
* :variable:`CMAKE_OBJC_STANDARD_REQUIRED`
* :variable:`CMAKE_OBJCXX_STANDARD_REQUIRED`

Default values for :prop_tgt:`<LANG>_STANDARD_REQUIRED` target properties if
set when a target is created.

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

.. versionadded:: 3.29

This variable specify what is the type of data stored in variable
 :variable:`CMAKE_<LANG>_USING_LINKER_<TYPE>`. There are two possible values:

``FLAG``
  :variable:`CMAKE_<LANG>_USING_LINKER_<TYPE>` holds compiler flags. This is
  the default.

``TOOL``
  :variable:`CMAKE_<LANG>_USING_LINKER_<TYPE>` holds the path to the linker
  tool.


code:
CMAKE_<LANG>_USING_LINKER_<TYPE>
--------------------------------

.. versionadded:: 3.29

This variable defines how to specify the linker for the link step for the type
as specified by the variable :variable:`CMAKE_LINKER_TYPE` or the target
property :prop_tgt:`LINKER_TYPE`. It can hold compiler flags for the link step
or directly the linker tool. The type of data is given by the variable
:variable:`CMAKE_<LANG>_USING_LINKER_MODE`.

For example, to specify the ``LLVM`` linker for ``GNU`` compilers, we have:

.. code-block:: cmake

  set(CMAKE_C_USING_LINKER_LLD "-fuse-ld=lld")

Or on ``Windows`` platform, for ``Clang`` compilers simulating ``MSVC``, we
have:

.. code-block:: cmake

  set(CMAKE_C_USING_LINKER_LLD "-fuse-ld=lld-link")

And for the ``MSVC`` compiler, linker is directly used, so we have:

.. code-block:: cmake

  set(CMAKE_C_USING_LINKER_LLD "/path/to/lld-link.exe")
  set(CMAKE_C_USING_LINKER_MODE TOOL)


code:
CMAKE_<LANG>_VISIBILITY_PRESET
------------------------------

Default value for the :prop_tgt:`<LANG>_VISIBILITY_PRESET` target
property when a target is created.


code:
CMAKE_LIBRARY_ARCHITECTURE
--------------------------

Target architecture library directory name, if detected.

This is the value of :variable:`CMAKE_<LANG>_LIBRARY_ARCHITECTURE` as detected
for one of the enabled languages.


code:
CMAKE_LIBRARY_ARCHITECTURE_REGEX
--------------------------------

Regex matching possible target architecture library directory names.

This is used to detect :variable:`CMAKE_<LANG>_LIBRARY_ARCHITECTURE` from the
implicit linker search path by matching the ``<arch>`` name.


code:
CMAKE_LIBRARY_OUTPUT_DIRECTORY
------------------------------

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

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


code:
CMAKE_LIBRARY_OUTPUT_DIRECTORY_<CONFIG>
---------------------------------------

.. versionadded:: 3.3

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

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


code:
CMAKE_LIBRARY_PATH
------------------

:ref:`Semicolon-separated list <CMake Language Lists>` of directories specifying a search path
for the :command:`find_library` command.  By default it is empty, it is
intended to be set by the project.

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

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


code:
CMAKE_LIBRARY_PATH_FLAG
-----------------------

The flag to be used to add a library search path to a compiler.

The flag will be used to specify a library directory to the compiler.
On most compilers this is ``-L``.


code:
CMAKE_LINKER_TYPE
-----------------

.. versionadded:: 3.29

Specify which linker will be used for the link step.

.. note::
  It is assumed that the linker specified is fully compatible with the standard
  one. CMake will not do any options translation.

This variable is used to initialize the :prop_tgt:`LINKER_TYPE` target
property when they are created by calls to :command:`add_library` or
:command:`add_executable` commands. It is meaningful only for targets having a
link step. If set, its value is also used by the :command:`try_compile`
command.

.. include:: LINKER_PREDEFINED_TYPES.txt


code:
CMAKE_LINK_DEF_FILE_FLAG
------------------------

Linker flag to be used to specify a ``.def`` file for dll creation.

The flag will be used to add a ``.def`` file when creating a dll on
Windows; this is only defined on Windows.


code:
CMAKE_LINK_DEPENDS_NO_SHARED
----------------------------

Whether to skip link dependencies on shared library files.

This variable initializes the :prop_tgt:`LINK_DEPENDS_NO_SHARED` property on
targets when they are created.  See that target property for
additional information.


code:
CMAKE_LINK_DEPENDS_USE_LINKER
-----------------------------

.. versionadded:: 3.27

For the :ref:`Makefile <Makefile Generators>` and
:ref:`Ninja <Ninja Generators>` generators, link dependencies are now, for a
selection of linkers, generated by the linker itself. By defining this
variable with value ``FALSE``, you can deactivate this feature.

This feature is also deactivated if the :prop_tgt:`LINK_DEPENDS_NO_SHARED`
target property is true.

.. note::

  CMake version |release| defaults this variable to ``FALSE`` because
  GNU binutils linkers (``ld``, ``ld.bfd``, ``ld.gold``) generate spurious
  dependencies on temporary files when LTO is enabled.  See `GNU bug 30568`_.

.. _`GNU bug 30568`: https://sourceware.org/bugzilla/show_bug.cgi?id=30568


code:
CMAKE_LINK_DIRECTORIES_BEFORE
-----------------------------

.. versionadded:: 3.13

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

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


code:
CMAKE_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.
Both of the following conditions must be met for this variable to have any
effect:

* The associated :variable:`CMAKE_LINK_GROUP_USING_<FEATURE>_SUPPORTED`
  variable must be set to true.

* There is no language-specific definition for the same ``<FEATURE>``.
  This means :variable:`CMAKE_<LANG>_LINK_GROUP_USING_<FEATURE>_SUPPORTED`
  cannot be true for the link language used by the target for which the
  :genex:`LINK_GROUP` generator expression is evaluated.

The :variable:`CMAKE_<LANG>_LINK_GROUP_USING_<FEATURE>` variable should be
defined instead for features that are dependent on the link language.

.. include:: CMAKE_LINK_GROUP_USING_FEATURE.txt


code:
Feature names are case-sensitive and may only contain letters, numbers
and underscores.  Feature names defined in all uppercase are reserved for
CMake's own built-in features (see `Predefined Features`_ further below).

Feature Definitions
^^^^^^^^^^^^^^^^^^^

A group feature definition is a list that contains exactly two elements:

::

  <PREFIX> <SUFFIX>

On the linker command line, ``<PREFIX>`` will precede the list of libraries
in the group and ``<SUFFIX>`` will follow after.

For the elements of this variable, the ``LINKER:`` prefix can be used.

.. include:: ../command/LINK_OPTIONS_LINKER.txt
  :start-line: 3

Examples
^^^^^^^^

Solving cross-references between two static libraries
"""""""""""""""""""""""""""""""""""""""""""""""""""""

A project may define two or more static libraries which have circular
dependencies between them.  In order for the linker to resolve all symbols
at link time, it may need to search repeatedly among the libraries until no
new undefined references are created.  Different linkers use different syntax
for achieving this.  The following example shows how this may be implemented
for some linkers.  Note that this is for illustration purposes only.
Projects should use the built-in ``RESCAN`` group feature instead
(see `Predefined Features`_), which provides a more complete and more robust
implementation of this functionality.

.. code-block:: cmake

  set(CMAKE_C_LINK_GROUP_USING_cross_refs_SUPPORTED TRUE)
  if(CMAKE_C_COMPILER_ID STREQUAL "GNU" AND CMAKE_SYSTEM_NAME STREQUAL "Linux")
    set(CMAKE_C_LINK_GROUP_USING_cross_refs
      "LINKER:--start-group"
      "LINKER:--end-group"
    )
  elseif(CMAKE_C_COMPILER_ID STREQUAL "SunPro" AND CMAKE_SYSTEM_NAME STREQUAL "SunOS")
    set(CMAKE_C_LINK_GROUP_USING_cross_refs
      "LINKER:-z,rescan-start"
      "LINKER:-z,rescan-end"
    )
  else()
    # feature not yet supported for the other environments
    set(CMAKE_C_LINK_GROUP_USING_cross_refs_SUPPORTED FALSE)
  endif()

  add_library(lib1 STATIC ...)
  add_library(lib2 SHARED ...)

  if(CMAKE_C_LINK_GROUP_USING_cross_refs_SUPPORTED)
    target_link_libraries(lib2 PRIVATE "$<LINK_GROUP:cross_refs,lib1,external>")
  else()
    target_link_libraries(lib2 PRIVATE lib1 external)
  endif()

CMake will generate the following linker command line fragments when linking
``lib2``:

* ``GNU``: ``-Wl,--start-group /path/to/lib1.a -lexternal -Wl,--end-group``
* ``SunPro``: ``-Wl,-z,rescan-start /path/to/lib1.a -lexternal -Wl,-z,rescan-end``

Predefined Features
^^^^^^^^^^^^^^^^^^^

The following built-in group features are pre-defined by CMake:

.. include:: LINK_GROUP_PREDEFINED_FEATURES.txt


code:
CMAKE_LINK_GROUP_USING_<FEATURE>_SUPPORTED
------------------------------------------

.. versionadded:: 3.24

This variable specifies whether the ``<FEATURE>`` is supported regardless of
the link language.  If this variable is true, then the ``<FEATURE>`` must
be defined by :variable:`CMAKE_LINK_GROUP_USING_<FEATURE>`.

Note that this variable has no effect if
:variable:`CMAKE_<LANG>_LINK_GROUP_USING_<FEATURE>_SUPPORTED` is true for
the link language of the target.


code:
CMAKE_LINK_INTERFACE_LIBRARIES
------------------------------

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

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


code:
CMAKE_LINK_LIBRARIES_ONLY_TARGETS
---------------------------------

.. versionadded:: 3.23

Set this variable to initialize the :prop_tgt:`LINK_LIBRARIES_ONLY_TARGETS`
property of non-imported targets when they are created.  Setting it to true
enables an additional check that all items named by
:command:`target_link_libraries` that can be target names are actually names
of existing targets.  See the target property documentation for details.


code:
CMAKE_LINK_LIBRARY_FILE_FLAG
----------------------------

Flag to be used to link a library specified by a path to its file.

The flag will be used before a library file path is given to the
linker.  This is needed only on very few platforms.


code:
CMAKE_LINK_LIBRARY_FLAG
-----------------------

Flag to be used to link a library into an executable.

The flag will be used to specify a library to link to an executable.
On most compilers this is ``-l``.


code:
CMAKE_LINK_LIBRARY_SUFFIX
-------------------------

The suffix for libraries that you link to.

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


code:
CMAKE_LINK_LIBRARY_USING_<FEATURE>
----------------------------------

.. versionadded:: 3.24

This variable defines how to link a library or framework for the specified
``<FEATURE>`` when a :genex:`LINK_LIBRARY` generator expression is used.
Both of the following conditions must be met for this variable to have any
effect:

* The associated :variable:`CMAKE_LINK_LIBRARY_USING_<FEATURE>_SUPPORTED`
  variable must be set to true.

* There is no language-specific definition for the same ``<FEATURE>``.
  This means :variable:`CMAKE_<LANG>_LINK_LIBRARY_USING_<FEATURE>_SUPPORTED`
  cannot be true for the link language used by the target for which the
  :genex:`LINK_LIBRARY` generator expression is evaluated.

.. include:: CMAKE_LINK_LIBRARY_USING_FEATURE.txt


code:
Feature names are case-sensitive and may only contain letters, numbers
and underscores.  Feature names defined in all uppercase are reserved for
CMake's own built-in features (see `Predefined Features`_ further below).

Feature Definitions
^^^^^^^^^^^^^^^^^^^

A library feature definition is a list that contains one or three elements:

::

  [<PREFIX>] <LIBRARY_EXPRESSION> [<SUFFIX>]

When ``<PREFIX>`` and ``<SUFFIX>`` are specified, they precede and follow
respectively the whole list of libraries specified in the
:genex:`LINK_LIBRARY` expression, not each library item individually.
There is no guarantee that the list of specified libraries will be kept
grouped together though, so the ``<PREFIX>`` and ``<SUFFIX>`` may appear
more than once if the library list is reorganized by CMake to satisfy other
constraints.  This means constructs like ``--start-group`` and ``--end-group``,
as supported by the GNU ``ld`` linker, cannot be used in this way.  The
:genex:`LINK_GROUP` generator expression should be used instead for such
constructs.

``<LIBRARY_EXPRESSION>`` is used to specify the pattern for constructing the
corresponding fragment on the linker command line for each library.
The following placeholders can be used in the expression:

* ``<LIBRARY>`` is expanded to the full path to the library for CMake targets,
  or to a platform-specific value based on the item otherwise (the same as
  ``<LINK_ITEM>`` on Windows, or the library base name for other platforms).
* ``<LINK_ITEM>`` is expanded to how the library would normally be linked on
  the linker command line.
* ``<LIB_ITEM>`` is expanded to the full path to the library for CMake targets,
  or the item itself exactly as specified in the ``<LIBRARY_EXPRESSION>``
  otherwise.

In addition to the above, it is possible to have one pattern for paths
(CMake targets and external libraries specified with file paths) and another
for other items specified by name only.  The ``PATH{}`` and ``NAME{}`` wrappers
can be used to provide the expansion for those two cases, respectively.
When wrappers are used, both must be present.  For example:

.. code-block:: cmake

  set(CMAKE_LINK_LIBRARY_USING_weak_library
      "PATH{-weak_library <LIBRARY>}NAME{LINKER:-weak-l<LIB_ITEM>}"
  )

For all three elements of this variable (``<PREFIX>``, ``<LIBRARY_EXPRESSION>``,
and ``<SUFFIX>``), the ``LINKER:`` prefix can be used.

.. include:: ../command/LINK_OPTIONS_LINKER.txt
  :start-line: 3

Examples
^^^^^^^^

Loading a whole static library
""""""""""""""""""""""""""""""

A common need is to prevent the linker from discarding any symbols from a
static library.  Different linkers use different syntax for achieving this.
The following example shows how this may be implemented for some linkers.
Note that this is for illustration purposes only.  Projects should use the
built-in ``WHOLE_ARCHIVE`` feature instead (see `Predefined Features`_), which
provides a more complete and more robust implementation of this functionality.

.. code-block:: cmake

  set(CMAKE_C_LINK_LIBRARY_USING_load_archive_SUPPORTED TRUE)
  if(CMAKE_C_COMPILER_ID STREQUAL "AppleClang")
    set(CMAKE_C_LINK_LIBRARY_USING_load_archive "-force_load <LIB_ITEM>")
  elseif(CMAKE_C_COMPILER_ID STREQUAL "GNU" AND CMAKE_SYSTEM_NAME STREQUAL "Linux")
    set(CMAKE_C_LINK_LIBRARY_USING_load_archive
      "LINKER:--push-state,--whole-archive"
      "<LINK_ITEM>"
      "LINKER:--pop-state"
    )
  elseif(CMAKE_C_COMPILER_ID STREQUAL "MSVC")
    set(CMAKE_C_LINK_LIBRARY_USING_load_archive "/WHOLEARCHIVE:<LIBRARY>")
  else()
    # feature not yet supported for the other environments
    set(CMAKE_C_LINK_LIBRARY_USING_load_archive_SUPPORTED FALSE)
  endif()

  add_library(lib1 STATIC ...)
  add_library(lib2 SHARED ...)

  if(CMAKE_C_LINK_LIBRARY_USING_load_archive_SUPPORTED)
    # The -force_load Apple linker option requires a file name
    set(external_lib
      "$<IF:$<LINK_LANG_AND_ID:C,AppleClang>,libexternal.a,external>"
    )
    target_link_libraries(lib2 PRIVATE
      "$<LINK_LIBRARY:load_archive,lib1,${external_lib}>"
    )
  else()
    target_link_libraries(lib2 PRIVATE lib1 external)
  endif()

CMake will generate the following link expressions:

* ``AppleClang``: ``-force_load /path/to/lib1.a -force_load libexternal.a``
* ``GNU``: ``-Wl,--push-state,--whole-archive /path/to/lib1.a -lexternal -Wl,--pop-state``
* ``MSVC``: ``/WHOLEARCHIVE:/path/to/lib1.lib /WHOLEARCHIVE:external.lib``

Linking a library as weak
"""""""""""""""""""""""""

On macOS, it is possible to link a library in weak mode (the library and all
references are marked as weak imports).  Different flags must be used for a
library specified by file path compared to one specified by name.
This constraint can be solved using ``PATH{}`` and ``NAME{}`` wrappers.
Again, the following example shows how this may be implemented for some
linkers, but it is for illustration purposes only.  Projects should use the
built-in ``WEAK_FRAMEWORK`` or ``WEAK_LIBRARY`` features instead (see
`Predefined Features`_), which provide more complete and more robust
implementations of this functionality.

.. code-block:: cmake

  if (CMAKE_C_COMPILER_ID STREQUAL "AppleClang")
    set(CMAKE_LINK_LIBRARY_USING_weak_library
        "PATH{-weak_library <LIBRARY>}NAME{LINKER:-weak-l<LIB_ITEM>}"
    )
    set(CMAKE_LINK_LIBRARY_USING_weak_library_SUPPORTED TRUE)
  endif()

  add_library(lib SHARED ...)
  add_executable(main ...)
  if(CMAKE_LINK_LIBRARY_USING_weak_library_SUPPORTED)
    target_link_libraries(main PRIVATE "$<LINK_LIBRARY:weak_library,lib,external>")
  else()
    target_link_libraries(main PRIVATE lib external)
  endif()

CMake will generate the following linker command line fragment when linking
``main`` using the ``AppleClang`` toolchain:

``-weak_library /path/to/lib -Xlinker -weak-lexternal``.

Predefined Features
^^^^^^^^^^^^^^^^^^^

The following built-in library features are pre-defined by CMake:

.. include:: LINK_LIBRARY_PREDEFINED_FEATURES.txt


code:
CMAKE_LINK_LIBRARY_USING_<FEATURE>_SUPPORTED
--------------------------------------------

.. versionadded:: 3.24

Set to ``TRUE`` if the ``<FEATURE>``, as defined by variable
:variable:`CMAKE_LINK_LIBRARY_USING_<FEATURE>`, is supported regardless the
linker language.

.. note::

  This variable is evaluated if, and only if, the variable
  :variable:`CMAKE_<LANG>_LINK_LIBRARY_USING_<FEATURE>_SUPPORTED` is not
  defined.


code:
CMAKE_LINK_SEARCH_END_STATIC
----------------------------

.. versionadded:: 3.4

End a link line such that static system libraries are used.

Some linkers support switches such as ``-Bstatic`` and ``-Bdynamic`` to
determine whether to use static or shared libraries for ``-lXXX`` options.
CMake uses these options to set the link type for libraries whose full
paths are not known or (in some cases) are in implicit link
directories for the platform.  By default CMake adds an option at the
end of the library list (if necessary) to set the linker search type
back to its starting type.  This property switches the final linker
search type to ``-Bstatic`` regardless of how it started.

This variable is used to initialize the target property
:prop_tgt:`LINK_SEARCH_END_STATIC` for all targets. If set, its
value is also used by the :command:`try_compile` command.

See also :variable:`CMAKE_LINK_SEARCH_START_STATIC`.


code:
CMAKE_LINK_SEARCH_START_STATIC
------------------------------

.. versionadded:: 3.4

Assume the linker looks for static libraries by default.

Some linkers support switches such as ``-Bstatic`` and ``-Bdynamic`` to
determine whether to use static or shared libraries for ``-lXXX`` options.
CMake uses these options to set the link type for libraries whose full
paths are not known or (in some cases) are in implicit link
directories for the platform.  By default the linker search type is
assumed to be ``-Bdynamic`` at the beginning of the library list.  This
property switches the assumption to ``-Bstatic``.  It is intended for use
when linking an executable statically (e.g.  with the GNU ``-static``
option).

This variable is used to initialize the target property
:prop_tgt:`LINK_SEARCH_START_STATIC` for all targets.  If set, its
value is also used by the :command:`try_compile` command.

See also :variable:`CMAKE_LINK_SEARCH_END_STATIC`.


code:
CMAKE_LINK_WHAT_YOU_USE
-----------------------

.. versionadded:: 3.7

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


code:
CMAKE_LINK_WHAT_YOU_USE_CHECK
-----------------------------

.. versionadded:: 3.22

Defines the command executed after the link step to check libraries usage.
This check is currently only defined on ``ELF`` platforms with value
``ldd -u -r``.

See also :variable:`CMAKE_<LANG>_LINK_WHAT_YOU_USE_FLAG` variables.


code:
CMAKE_MACOSX_BUNDLE
-------------------

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

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

This variable is set to ``ON`` by default if :variable:`CMAKE_SYSTEM_NAME`
equals to :ref:`iOS, tvOS, visionOS or watchOS <Cross Compiling for iOS, tvOS, visionOS, or watchOS>`.


code:
CMAKE_MACOSX_RPATH
-------------------

Whether to use rpaths on macOS and iOS.

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


code:
CMAKE_MAJOR_VERSION
-------------------

First version number component of the :variable:`CMAKE_VERSION`
variable.


code:
CMAKE_MAKE_PROGRAM
------------------

Tool that can launch the native build system.
The value may be the full path to an executable or just the tool
name if it is expected to be in the ``PATH``.

The tool selected depends on the :variable:`CMAKE_GENERATOR` used
to configure the project:

* The :ref:`Makefile Generators` set this to ``make``, ``gmake``, or
  a generator-specific tool (e.g. ``nmake`` for :generator:`NMake Makefiles`).

  These generators store ``CMAKE_MAKE_PROGRAM`` in the CMake cache
  so that it may be edited by the user.

* The :generator:`Ninja` generator sets this to ``ninja``.

  This generator stores ``CMAKE_MAKE_PROGRAM`` in the CMake cache
  so that it may be edited by the user.

* The :generator:`Xcode` generator sets this to ``xcodebuild``.

  This generator prefers to lookup the build tool at build time
  rather than to store ``CMAKE_MAKE_PROGRAM`` in the CMake cache
  ahead of time.  This is because ``xcodebuild`` is easy to find.

  For compatibility with versions of CMake prior to 3.2, if
  a user or project explicitly adds ``CMAKE_MAKE_PROGRAM`` to
  the CMake cache then CMake will use the specified value.

* The :ref:`Visual Studio Generators` set this to the full path to
  ``MSBuild.exe`` (VS >= 10), ``devenv.com`` (VS 7,8,9), or
  ``VCExpress.exe`` (VS Express 8,9).
  (See also variables
  :variable:`CMAKE_VS_MSBUILD_COMMAND` and
  :variable:`CMAKE_VS_DEVENV_COMMAND`.

  These generators prefer to lookup the build tool at build time
  rather than to store ``CMAKE_MAKE_PROGRAM`` in the CMake cache
  ahead of time.  This is because the tools are version-specific
  and can be located using the Windows Registry.  It is also
  necessary because the proper build tool may depend on the
  project content (e.g. the Intel Fortran plugin to VS 10 and 11
  requires ``devenv.com`` to build its ``.vfproj`` project files
  even though ``MSBuild.exe`` is normally preferred to support
  the :variable:`CMAKE_GENERATOR_TOOLSET`).

  For compatibility with versions of CMake prior to 3.0, if
  a user or project explicitly adds ``CMAKE_MAKE_PROGRAM`` to
  the CMake cache then CMake will use the specified value if
  possible.

* The :generator:`Green Hills MULTI` generator sets this to the full
  path to ``gbuild.exe(Windows)`` or ``gbuild(Linux)`` based upon
  the toolset being used.

  Once the generator has initialized a particular value for this
  variable, changing the value has undefined behavior.

The ``CMAKE_MAKE_PROGRAM`` variable is set for use by project code.
The value is also used by the :option:`cmake --build` and
:option:`ctest --build-and-test` tools to launch the native
build process.


code:
CMAKE_MAP_IMPORTED_CONFIG_<CONFIG>
----------------------------------

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

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


code:
CMAKE_MATCH_COUNT
-----------------

.. versionadded:: 3.2

The number of matches with the last regular expression.

When a regular expression match is used, CMake fills in
:variable:`CMAKE_MATCH_<n>` variables with the match contents.
The ``CMAKE_MATCH_COUNT`` variable holds the number of match
expressions when these are filled.


code:
CMAKE_MATCH_<n>
---------------

Capture group ``<n>`` matched by the last regular expression, for groups
0 through 9.  Group 0 is the entire match.  Groups 1 through 9 are the
subexpressions captured by ``()`` syntax.

When a regular expression match is used, CMake fills in ``CMAKE_MATCH_<n>``
variables with the match contents.  The :variable:`CMAKE_MATCH_COUNT`
variable holds the number of match expressions when these are filled.


code:
CMAKE_MAXIMUM_RECURSION_DEPTH
-----------------------------

.. versionadded:: 3.14

Maximum recursion depth for CMake scripts. It is intended to be set on the
command line with ``-DCMAKE_MAXIMUM_RECURSION_DEPTH=<x>``, or within
``CMakeLists.txt`` by projects that require a large recursion depth. Projects
that set this variable should provide the user with a way to override it. For
example:

.. code-block:: cmake

  # About to perform deeply recursive actions
  if(NOT CMAKE_MAXIMUM_RECURSION_DEPTH)
    set(CMAKE_MAXIMUM_RECURSION_DEPTH 2000)
  endif()

If it is not set, or is set to a non-integer value, a sensible default limit is
used. If the recursion limit is reached, the script terminates immediately with
a fatal error.

Calling any of the following commands increases the recursion depth:

* :command:`include`
* :command:`find_package`
* :command:`add_subdirectory`
* :command:`try_compile`
* :command:`ctest_read_custom_files`
* :command:`ctest_run_script` (unless ``NEW_PROCESS`` is specified)
* User-defined :command:`function`'s and :command:`macro`'s (note that
  :command:`function` and :command:`macro` themselves don't increase recursion
  depth)
* Reading or writing variables that are being watched by a
  :command:`variable_watch`

See also the :envvar:`CMAKE_MAXIMUM_RECURSION_DEPTH` environment variable.


code:
CMAKE_MESSAGE_CONTEXT
---------------------

.. versionadded:: 3.17

When enabled by the :option:`cmake --log-context` command line
option or the :variable:`CMAKE_MESSAGE_CONTEXT_SHOW` variable, the
:command:`message` command converts the ``CMAKE_MESSAGE_CONTEXT`` list into a
dot-separated string surrounded by square brackets and prepends it to each line
for messages of log levels ``NOTICE`` and below.

For logging contexts to work effectively, projects should generally
``APPEND`` and ``POP_BACK`` an item to the current value of
``CMAKE_MESSAGE_CONTEXT`` rather than replace it.
Projects should not assume the message context at the top of the source tree
is empty, as there are scenarios where the context might have already been set
(e.g. hierarchical projects).

.. warning::

  Valid context names are restricted to anything that could be used
  as a CMake variable name.  All names that begin with an underscore
  or the string ``cmake_`` are also reserved for use by CMake and
  should not be used by projects.

Example:

.. code-block:: cmake

  function(bar)
    list(APPEND CMAKE_MESSAGE_CONTEXT "bar")
    message(VERBOSE "bar VERBOSE message")
  endfunction()

  function(baz)
    list(APPEND CMAKE_MESSAGE_CONTEXT "baz")
    message(DEBUG "baz DEBUG message")
  endfunction()

  function(foo)
    list(APPEND CMAKE_MESSAGE_CONTEXT "foo")
    bar()
    message(TRACE "foo TRACE message")
    baz()
  endfunction()

  list(APPEND CMAKE_MESSAGE_CONTEXT "top")

  message(VERBOSE "Before `foo`")
  foo()
  message(VERBOSE "After `foo`")

  list(POP_BACK CMAKE_MESSAGE_CONTEXT)

Which results in the following output:

.. code-block:: none

  -- [top] Before `foo`
  -- [top.foo.bar] bar VERBOSE message
  -- [top.foo] foo TRACE message
  -- [top.foo.baz] baz DEBUG message
  -- [top] After `foo`


code:
CMAKE_MESSAGE_CONTEXT_SHOW
--------------------------

.. versionadded:: 3.17

Setting this variable to true enables showing a context with each line
logged by the :command:`message` command (see :variable:`CMAKE_MESSAGE_CONTEXT`
for how the context itself is specified).

This variable is an alternative to providing the ``--log-context`` option
on the :manual:`cmake <cmake(1)>` command line.  Whereas the command line
option will apply only to that one CMake run, setting
``CMAKE_MESSAGE_CONTEXT_SHOW`` to true as a cache variable will ensure that
subsequent CMake runs will continue to show the message context.

Projects should not set ``CMAKE_MESSAGE_CONTEXT_SHOW``.  It is intended for
users so that they may control whether or not to include context with messages.


code:
CMAKE_MESSAGE_INDENT
--------------------

.. versionadded:: 3.16

The :command:`message` command joins the strings from this list and for
log levels of ``NOTICE`` and below, it prepends the resultant string to
each line of the message.

Example:

.. code-block:: cmake

  list(APPEND listVar one two three)

  message(VERBOSE [[Collected items in the "listVar":]])
  list(APPEND CMAKE_MESSAGE_INDENT "  ")

  foreach(item IN LISTS listVar)
    message(VERBOSE ${item})
  endforeach()

  list(POP_BACK CMAKE_MESSAGE_INDENT)
  message(VERBOSE "No more indent")

Which results in the following output:

.. code-block:: none

  -- Collected items in the "listVar":
  --   one
  --   two
  --   three
  -- No more indent


code:
CMAKE_MESSAGE_LOG_LEVEL
-----------------------

.. versionadded:: 3.17

When set, this variable specifies the logging level used by the
:command:`message` command.  Valid values are the same as those for the
:option:`--log-level <cmake --log-level>` command line option of the
:manual:`cmake(1)` program.  If this variable is set and the
:option:`--log-level <cmake --log-level>` command line option is
given, the command line option takes precedence.

The main advantage to using this variable is to make a log level persist
between CMake runs.  Setting it as a cache variable will ensure that
subsequent CMake runs will continue to use the chosen log level.

Projects should not set this variable, it is intended for users so that
they may control the log level according to their own needs.

.. versionadded:: 3.25
  See the :command:`cmake_language`
  :ref:`cmake_language <query_message_log_level>` command for a way to query
  the current message logging level.


code:
CMAKE_MFC_FLAG
--------------

Use the MFC library for an executable or dll.

Enables the use of the Microsoft Foundation Classes (MFC).
It should be set to ``1`` for the static MFC library, and
``2`` for the shared MFC library.  This is used in Visual Studio
project files.

Usage example:

.. code-block:: cmake

  add_definitions(-D_AFXDLL)
  set(CMAKE_MFC_FLAG 2)
  add_executable(CMakeSetup WIN32 ${SRCS})

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


code:
CMAKE_MINIMUM_REQUIRED_VERSION
------------------------------

The ``<min>`` version of CMake given to the most recent call to the
:command:`cmake_minimum_required(VERSION)` command in the current
variable scope or any parent variable scope.


code:
CMAKE_MINOR_VERSION
-------------------

Second version number component of the :variable:`CMAKE_VERSION`
variable.


code:
CMAKE_MODULE_LINKER_FLAGS
-------------------------

Linker flags to be used to create modules.

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


code:
CMAKE_MODULE_LINKER_FLAGS_<CONFIG>
----------------------------------

Flags to be used when linking a module.

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


code:
CMAKE_MODULE_LINKER_FLAGS_<CONFIG>_INIT
---------------------------------------

.. versionadded:: 3.7

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


code:
CMAKE_MODULE_LINKER_FLAGS_INIT
------------------------------

.. versionadded:: 3.7

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


code:
CMAKE_MODULE_PATH
-----------------

:ref:`Semicolon-separated list <CMake Language Lists>` of directories,
represented using forward slashes, specifying a search path for CMake modules
to be loaded by the :command:`include` or :command:`find_package` commands
before checking the default modules that come with CMake. By default it is
empty.  It is intended to be set by the project.


code:
CMAKE_MSVCIDE_RUN_PATH
----------------------

.. versionadded:: 3.10

Extra PATH locations that should be used when executing
:command:`add_custom_command` or :command:`add_custom_target` when using the
:generator:`Visual Studio 9 2008` (or above) generator. This allows
for running commands and using dll's that the IDE environment is not aware of.

If not set explicitly the value is initialized by the ``CMAKE_MSVCIDE_RUN_PATH``
environment variable, if set, and otherwise left empty.


code:
CMAKE_MSVC_DEBUG_INFORMATION_FORMAT
-----------------------------------

.. versionadded:: 3.25

Select the MSVC debug information format targeting the MSVC ABI.
This variable is used to initialize the
:prop_tgt:`MSVC_DEBUG_INFORMATION_FORMAT` property on all targets as they are
created.  It is also propagated by calls to the :command:`try_compile` command
into the test project.

The allowed values are:

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

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

.. code-block:: cmake

  set(CMAKE_MSVC_DEBUG_INFORMATION_FORMAT "$<$<CONFIG:Debug,RelWithDebInfo>:ProgramDatabase>")

selects for all following targets the program database debug information format
for the Debug configuration.

If this variable is not set, the :prop_tgt:`MSVC_DEBUG_INFORMATION_FORMAT`
target property will not be set automatically.  If that property is not set,
CMake selects a debug information format using the default value
``$<$<CONFIG:Debug,RelWithDebInfo>:ProgramDatabase>``, if supported by the
compiler, and otherwise ``$<$<CONFIG:Debug,RelWithDebInfo>:Embedded>``.

.. note::

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


code:
CMAKE_MSVC_RUNTIME_LIBRARY
--------------------------

.. versionadded:: 3.15

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

The allowed values are:

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

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

.. code-block:: cmake

  set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>")

selects for all following targets a multi-threaded statically-linked runtime
library with or without debug information depending on the configuration.

If this variable is not set then the :prop_tgt:`MSVC_RUNTIME_LIBRARY` target
property will not be set automatically.  If that property is not set then
CMake uses the default value ``MultiThreaded$<$<CONFIG:Debug>:Debug>DLL``
to select a MSVC runtime library.

.. note::

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


code:
CMAKE_NETRC
-----------

.. versionadded:: 3.11

This variable is used to initialize the ``NETRC`` option for the
:command:`file(DOWNLOAD)` and :command:`file(UPLOAD)` commands.
See those commands for additional information.

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

The local option takes precedence over this variable.


code:
CMAKE_NETRC_FILE
----------------

.. versionadded:: 3.11

This variable is used to initialize the ``NETRC_FILE`` option for the
:command:`file(DOWNLOAD)` and :command:`file(UPLOAD)` commands.
See those commands for additional information.

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

The local option takes precedence over this variable.


code:
CMAKE_NINJA_OUTPUT_PATH_PREFIX
------------------------------

.. versionadded:: 3.6

Tell the :ref:`Ninja Generators` to add a prefix to every output path in
``build.ninja``.  A trailing slash is appended to the prefix, if missing.

This is useful when the generated ninja file is meant to be embedded as a
``subninja`` file into a *super* ninja project.  For example, the command:

.. code-block:: shell

  cd super-build-dir &&
  cmake -G Ninja -S /path/to/src -B sub -DCMAKE_NINJA_OUTPUT_PATH_PREFIX=sub/
  #                                 ^^^---------- these match -----------^^^

generates a build directory with its top-level (:variable:`CMAKE_BINARY_DIR`)
in ``super-build-dir/sub``.  The path to the build directory ends in the
output path prefix.  This makes it suitable for use in a separately-written
``super-build-dir/build.ninja`` file with a directive like this::

  subninja sub/build.ninja

The ``auto-regeneration`` rule in ``super-build-dir/build.ninja`` must
have an order-only dependency on ``sub/build.ninja``.

.. versionadded:: 3.27

  The :generator:`Ninja Multi-Config` generator supports this variable.

.. note::
  When ``CMAKE_NINJA_OUTPUT_PATH_PREFIX`` is set, the project generated
  by CMake cannot be used as a standalone project.  No default targets
  are specified.

  The value of ``CMAKE_NINJA_OUTPUT_PATH_PREFIX`` must match one or more
  path components at the *end* of :variable:`CMAKE_BINARY_DIR`, or the
  behavior is undefined.  However, this requirement is not checked
  automatically.


code:
CMAKE_NOT_USING_CONFIG_FLAGS
----------------------------

Skip ``_BUILD_TYPE`` flags if true.

This is an internal flag used by the generators in CMake to tell CMake
to skip the ``_BUILD_TYPE`` flags.


code:
CMAKE_NO_BUILTIN_CHRPATH
------------------------

Do not use the builtin binary editor to fix runtime library search
paths on installation.

When an ELF or XCOFF binary needs to have a different runtime library
search path after installation than it does in the build tree, CMake uses
a builtin editor to change the runtime search path in the installed copy.
If this variable is set to true then CMake will relink the binary before
installation instead of using its builtin editor.

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

.. versionadded:: 3.20

  This variable also applies to XCOFF binaries' LIBPATH.  Prior to the
  addition of the XCOFF editor in CMake 3.20, this variable applied only
  to ELF binaries' RPATH/RUNPATH.


code:
CMAKE_NO_SYSTEM_FROM_IMPORTED
-----------------------------

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

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


code:
CMAKE_OBJCXX_EXTENSIONS
-----------------------

.. versionadded:: 3.16

Default value for :prop_tgt:`OBJCXX_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_OBJCXX_STANDARD
---------------------

.. versionadded:: 3.16

Default value for :prop_tgt:`OBJCXX_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_OBJCXX_STANDARD_REQUIRED
------------------------------

.. versionadded:: 3.16

Default value for :prop_tgt:`OBJCXX_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_OBJC_EXTENSIONS
---------------------

.. versionadded:: 3.16

Default value for :prop_tgt:`OBJC_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_OBJC_STANDARD
-------------------

.. versionadded:: 3.16

Default value for :prop_tgt:`OBJC_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_OBJC_STANDARD_REQUIRED
----------------------------

.. versionadded:: 3.16

Default value for :prop_tgt:`OBJC_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_OBJECT_PATH_MAX
---------------------

Maximum object file full-path length allowed by native build tools.

CMake computes for every source file an object file name that is
unique to the source file and deterministic with respect to the full
path to the source file.  This allows multiple source files in a
target to share the same name if they lie in different directories
without rebuilding when one is added or removed.  However, it can
produce long full paths in a few cases, so CMake shortens the path
using a hashing scheme when the full path to an object file exceeds a
limit.  CMake has a built-in limit for each platform that is
sufficient for common tools, but some native tools may have a lower
limit.  This variable may be set to specify the limit explicitly.  The
value must be an integer no less than 128.


code:
CMAKE_OPTIMIZE_DEPENDENCIES
---------------------------

.. versionadded:: 3.19

Initializes the :prop_tgt:`OPTIMIZE_DEPENDENCIES` target property.


code:
CMAKE_OSX_ARCHITECTURES
-----------------------

Target specific architectures for macOS and iOS.

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

.. include:: CMAKE_OSX_VARIABLE.txt


code:
CMAKE_OSX_DEPLOYMENT_TARGET
---------------------------

Specify the minimum version of the target platform (e.g. macOS or iOS)
on which the target binaries are to be deployed.  CMake uses this
variable value for the ``-mmacosx-version-min`` flag or their respective
target platform equivalents.  For older Xcode versions that shipped
multiple macOS SDKs this variable also helps to choose the SDK in case
:variable:`CMAKE_OSX_SYSROOT` is unset.

If not set explicitly the value is initialized by the
``MACOSX_DEPLOYMENT_TARGET`` environment variable, if set,
and otherwise computed based on the host platform.

.. include:: CMAKE_OSX_VARIABLE.txt


code:
CMAKE_OSX_SYSROOT
-----------------

Specify the location or name of the macOS platform SDK to be used.
CMake uses this value to compute the value of the ``-isysroot`` flag
or equivalent and to help the ``find_*`` commands locate files in
the SDK.

If not set explicitly the value is initialized by the ``SDKROOT``
environment variable, if set, and otherwise computed based on the
:variable:`CMAKE_OSX_DEPLOYMENT_TARGET` or the host platform.

.. include:: CMAKE_OSX_VARIABLE.txt


code:
The value of this variable should be set prior to the first
:command:`project` or :command:`enable_language` command invocation
because it may influence configuration of the toolchain and flags.
It is intended to be set locally by the user creating a build tree.
This variable should be set as a ``CACHE`` entry (or else CMake may
remove it while initializing a cache entry of the same name) unless
policy :policy:`CMP0126` is set to ``NEW``.

Despite the ``OSX`` part in the variable name(s) they apply also to
other SDKs than macOS like iOS, tvOS, visionOS, or watchOS.

This variable is ignored on platforms other than Apple.


code:
CMAKE_PARENT_LIST_FILE
----------------------

Full path to the CMake file that included the current one.

While processing a CMake file loaded by :command:`include` or
:command:`find_package` this variable contains the full path to the file
including it.  The top of the include stack is always the ``CMakeLists.txt``
for the current directory.  See also :variable:`CMAKE_CURRENT_LIST_FILE`.


code:
CMAKE_PATCH_VERSION
-------------------

Third version number component of the :variable:`CMAKE_VERSION`
variable.


code:
CMAKE_PCH_INSTANTIATE_TEMPLATES
-------------------------------

.. versionadded:: 3.19

This variable is used to initialize the :prop_tgt:`PCH_INSTANTIATE_TEMPLATES`
property of targets when they are created.


code:
CMAKE_PCH_WARN_INVALID
----------------------

.. versionadded:: 3.18

This variable is used to initialize the :prop_tgt:`PCH_WARN_INVALID`
property of targets when they are created.


code:
CMAKE_PDB_OUTPUT_DIRECTORY
--------------------------

Output directory for MS debug symbol ``.pdb`` files generated by the
linker for executable and shared library targets.

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


code:
CMAKE_PDB_OUTPUT_DIRECTORY_<CONFIG>
-----------------------------------

Per-configuration output directory for MS debug symbol ``.pdb`` files
generated by the linker for executable and shared library targets.

This is a per-configuration version of :variable:`CMAKE_PDB_OUTPUT_DIRECTORY`.
This variable is used to initialize the
:prop_tgt:`PDB_OUTPUT_DIRECTORY_<CONFIG>`
property on all the targets.  See that target property for additional
information.


code:
CMAKE_PLATFORM_NO_VERSIONED_SONAME
----------------------------------

.. versionadded:: 3.1

This variable is used to globally control whether the
:prop_tgt:`VERSION` and :prop_tgt:`SOVERSION` target
properties should be used for shared libraries.
When set to true, adding version information to each
shared library target is disabled.

By default this variable is set only on platforms where
CMake knows it is needed.   On other platforms, the
specified properties will be used for shared libraries.


code:
CMAKE_POLICY_DEFAULT_CMP<NNNN>
------------------------------

Default for CMake Policy ``CMP<NNNN>`` when it is otherwise left unset.

Commands :command:`cmake_minimum_required(VERSION)` and
:command:`cmake_policy(VERSION)` by default leave policies introduced after
the given version unset.  Set ``CMAKE_POLICY_DEFAULT_CMP<NNNN>`` to ``OLD``
or ``NEW`` to specify the default for policy ``CMP<NNNN>``, where ``<NNNN>``
is the policy number.

This variable should not be set by a project in CMake code as a way to
set its own policies; use :command:`cmake_policy(SET)` instead.  This
variable is meant to externally set policies for which a project has
not itself been updated:

* Users running CMake may set this variable in the cache
  (e.g. ``-DCMAKE_POLICY_DEFAULT_CMP<NNNN>=<OLD|NEW>``).  Set it to ``OLD``
  to quiet a policy warning while using old behavior or to ``NEW`` to
  try building the project with new behavior.

* Projects may set this variable before a call to :command:`add_subdirectory`
  that adds a third-party project in order to set its policies without
  modifying third-party code.


code:
CMAKE_POLICY_WARNING_CMP<NNNN>
------------------------------

Explicitly enable or disable the warning when CMake Policy ``CMP<NNNN>``
has not been set explicitly by :command:`cmake_policy` or implicitly
by :command:`cmake_minimum_required`. This is meaningful
only for the policies that do not warn by default:

* ``CMAKE_POLICY_WARNING_CMP0025`` controls the warning for
  policy :policy:`CMP0025`.
* ``CMAKE_POLICY_WARNING_CMP0047`` controls the warning for
  policy :policy:`CMP0047`.
* ``CMAKE_POLICY_WARNING_CMP0056`` controls the warning for
  policy :policy:`CMP0056`.
* ``CMAKE_POLICY_WARNING_CMP0060`` controls the warning for
  policy :policy:`CMP0060`.
* ``CMAKE_POLICY_WARNING_CMP0065`` controls the warning for
  policy :policy:`CMP0065`.
* ``CMAKE_POLICY_WARNING_CMP0066`` controls the warning for
  policy :policy:`CMP0066`.
* ``CMAKE_POLICY_WARNING_CMP0067`` controls the warning for
  policy :policy:`CMP0067`.
* ``CMAKE_POLICY_WARNING_CMP0082`` controls the warning for
  policy :policy:`CMP0082`.
* ``CMAKE_POLICY_WARNING_CMP0089`` controls the warning for
  policy :policy:`CMP0089`.
* ``CMAKE_POLICY_WARNING_CMP0102`` controls the warning for
  policy :policy:`CMP0102`.
* ``CMAKE_POLICY_WARNING_CMP0112`` controls the warning for
  policy :policy:`CMP0112`.
* ``CMAKE_POLICY_WARNING_CMP0116`` controls the warning for
  policy :policy:`CMP0116`.
* ``CMAKE_POLICY_WARNING_CMP0126`` controls the warning for
  policy :policy:`CMP0126`.
* ``CMAKE_POLICY_WARNING_CMP0128`` controls the warning for
  policy :policy:`CMP0128`.
* ``CMAKE_POLICY_WARNING_CMP0129`` controls the warning for
  policy :policy:`CMP0129`.
* ``CMAKE_POLICY_WARNING_CMP0133`` controls the warning for
  policy :policy:`CMP0133`.

This variable should not be set by a project in CMake code.  Project
developers running CMake may set this variable in their cache to
enable the warning (e.g. ``-DCMAKE_POLICY_WARNING_CMP<NNNN>=ON``).
Alternatively, running :manual:`cmake(1)` with the
:option:`--debug-output <cmake --debug-output>`,
:option:`--trace <cmake --trace>`, or
:option:`--trace-expand <cmake --trace-expand>` option will also
enable the warning.


code:
CMAKE_POSITION_INDEPENDENT_CODE
-------------------------------

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

This variable is used to initialize the
:prop_tgt:`POSITION_INDEPENDENT_CODE` property on all the targets.
See that target property for additional information.  If set, its
value is also used by the :command:`try_compile` command.


code:
CMAKE_PREFIX_PATH
-----------------

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

By default this is empty.  It is intended to be set by the project.

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

See also :variable:`CMAKE_SYSTEM_PREFIX_PATH`, :variable:`CMAKE_INCLUDE_PATH`,
:variable:`CMAKE_LIBRARY_PATH`, :variable:`CMAKE_PROGRAM_PATH`, and
:variable:`CMAKE_IGNORE_PATH`.


code:
CMAKE_PROGRAM_PATH
------------------

:ref:`Semicolon-separated list <CMake Language Lists>` of directories specifying a search path
for the :command:`find_program` command.  By default it is empty, it is
intended to be set by the project.

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

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


code:
CMAKE_PROJECT_DESCRIPTION
-------------------------

.. versionadded:: 3.9

The description of the top level project.

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

.. code-block:: cmake

  cmake_minimum_required(VERSION 3.0)
  project(First DESCRIPTION "I am First")
  project(Second DESCRIPTION "I am Second")
  add_subdirectory(sub)
  project(Third DESCRIPTION "I am Third")

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

.. code-block:: cmake

  project(SubProj DESCRIPTION "I am SubProj")
  message("CMAKE_PROJECT_DESCRIPTION = ${CMAKE_PROJECT_DESCRIPTION}")

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

  CMAKE_PROJECT_DESCRIPTION = I am Second

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


code:
CMAKE_PROJECT_HOMEPAGE_URL
--------------------------

.. versionadded:: 3.12

The homepage URL of the top level project.

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

.. code-block:: cmake

  cmake_minimum_required(VERSION 3.0)
  project(First HOMEPAGE_URL "http://first.example.com")
  project(Second HOMEPAGE_URL "http://second.example.com")
  add_subdirectory(sub)
  project(Third HOMEPAGE_URL "http://third.example.com")

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

.. code-block:: cmake

  project(SubProj HOMEPAGE_URL "http://subproj.example.com")
  message("CMAKE_PROJECT_HOMEPAGE_URL = ${CMAKE_PROJECT_HOMEPAGE_URL}")

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

  CMAKE_PROJECT_HOMEPAGE_URL = http://second.example.com

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


code:
CMAKE_PROJECT_INCLUDE
---------------------

.. versionadded:: 3.15

A CMake language file to be included as the last step of all
:command:`project` command calls.  This is intended for injecting custom code
into project builds without modifying their source.  See :ref:`Code Injection`
for a more detailed discussion of files potentially included during a
:command:`project` call.

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

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


code:
CMAKE_PROJECT_INCLUDE_BEFORE
----------------------------

.. versionadded:: 3.15

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

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

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


code:
CMAKE_PROJECT_NAME
------------------

The name of the top level project.

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

.. code-block:: cmake

  cmake_minimum_required(VERSION 3.0)
  project(First)
  project(Second)
  add_subdirectory(sub)
  project(Third)

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

.. code-block:: cmake

  project(SubProj)
  message("CMAKE_PROJECT_NAME = ${CMAKE_PROJECT_NAME}")

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

  CMAKE_PROJECT_NAME = Second

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


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

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

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

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