code:
install
-------

.. only:: html

   .. contents::

Specify rules to run at install time.

Synopsis
^^^^^^^^

.. parsed-literal::

  install(`TARGETS`_ <target>... [...])
  install(`IMPORTED_RUNTIME_ARTIFACTS`_ <target>... [...])
  install({`FILES`_ | `PROGRAMS`_} <file>... [...])
  install(`DIRECTORY`_ <dir>... [...])
  install(`SCRIPT`_ <file> [...])
  install(`CODE`_ <code> [...])
  install(`EXPORT`_ <export-name> [...])
  install(`RUNTIME_DEPENDENCY_SET`_ <set-name> [...])

Introduction
^^^^^^^^^^^^

This command generates installation rules for a project.  Install rules
specified by calls to the ``install()`` command within a source directory
are executed in order during installation.

.. versionchanged:: 3.14
  Install rules in subdirectories
  added by calls to the :command:`add_subdirectory` command are interleaved
  with those in the parent directory to run in the order declared (see
  policy :policy:`CMP0082`).

.. versionchanged:: 3.22
  The environment variable :envvar:`CMAKE_INSTALL_MODE` can override the
  default copying behavior of ``install()``.

.. _`common options`:

There are multiple signatures for this command.  Some of them define
installation options for files and targets.  Options common to
multiple signatures are covered here but they are valid only for
signatures that specify them.  The common options are:

``DESTINATION <dir>``
  Specify the directory on disk to which a file will be installed.
  ``<dir>`` should be a relative path.  An absolute path is allowed,
  but not recommended.

  When a relative path is given it is interpreted relative to the value
  of the :variable:`CMAKE_INSTALL_PREFIX` variable.
  The prefix can be relocated at install time using the ``DESTDIR``
  mechanism explained in the :variable:`CMAKE_INSTALL_PREFIX` variable
  documentation.

  As absolute paths do not work with the ``cmake --install`` command's
  :option:`--prefix <cmake--install --prefix>` option, or with the
  :manual:`cpack <cpack(1)>` installer generators, it is strongly recommended
  to use relative paths throughout for best support by package maintainers.
  In particular, there is no need to make paths absolute by prepending
  :variable:`CMAKE_INSTALL_PREFIX`; this prefix is used by default if
  the DESTINATION is a relative path.

  If an absolute path (with a leading slash or drive letter) is given
  it is used verbatim.

``PERMISSIONS <permission>...``
  Specify permissions for installed files.  Valid permissions are
  ``OWNER_READ``, ``OWNER_WRITE``, ``OWNER_EXECUTE``, ``GROUP_READ``,
  ``GROUP_WRITE``, ``GROUP_EXECUTE``, ``WORLD_READ``, ``WORLD_WRITE``,
  ``WORLD_EXECUTE``, ``SETUID``, and ``SETGID``.  Permissions that do
  not make sense on certain platforms are ignored on those platforms.

  If this option is used multiple times in a single call, its list
  of permissions accumulates.  If an :command:`install(TARGETS)` call
  uses `\<artifact-kind\>`_ arguments, a separate list of permissions
  is accumulated for each kind of artifact.

``CONFIGURATIONS <config>...``
  Specify a list of build configurations for which the install rule
  applies (Debug, Release, etc.).

  If this option is used multiple times in a single call, its list
  of configurations accumulates.  If an :command:`install(TARGETS)`
  call uses `\<artifact-kind\>`_ arguments, a separate list of
  configurations is accumulated for each kind of artifact.

``COMPONENT <component>``
  Specify an installation component name with which the install rule
  is associated, such as ``Runtime`` or ``Development``.  During
  component-specific installation only install rules associated with
  the given component name will be executed.  During a full installation
  all components are installed unless marked with ``EXCLUDE_FROM_ALL``.
  If ``COMPONENT`` is not provided a default component "Unspecified" is
  created.  The default component name may be controlled with the
  :variable:`CMAKE_INSTALL_DEFAULT_COMPONENT_NAME` variable.

``EXCLUDE_FROM_ALL``
  .. versionadded:: 3.6

  Specify that the file is excluded from a full installation and only
  installed as part of a component-specific installation

``RENAME <name>``
  Specify a name for an installed file that may be different from the
  original file.  Renaming is allowed only when a single file is
  installed by the command.

``OPTIONAL``
  Specify that it is not an error if the file to be installed does
  not exist.

.. versionadded:: 3.1
  Command signatures that install files may print messages during
  installation.  Use the :variable:`CMAKE_INSTALL_MESSAGE` variable
  to control which messages are printed.

.. versionadded:: 3.11
  Many of the ``install()`` variants implicitly create the directories
  containing the installed files. If
  :variable:`CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS` is set, these
  directories will be created with the permissions specified. Otherwise,
  they will be created according to the uname rules on Unix-like platforms.
  Windows platforms are unaffected.

Signatures
^^^^^^^^^^

.. signature::
  install(TARGETS <target>... [...])

  Install target :ref:`Output Artifacts` and associated files:

  .. code-block:: cmake

    install(TARGETS <target>... [EXPORT <export-name>]
            [RUNTIME_DEPENDENCIES <arg>...|RUNTIME_DEPENDENCY_SET <set-name>]
            [<artifact-option>...]
            [<artifact-kind> <artifact-option>...]...
            [INCLUDES DESTINATION [<dir> ...]]
            )

  where ``<artifact-option>...`` group may contain:

  .. code-block:: cmake

    [DESTINATION <dir>]
    [PERMISSIONS <permission>...]
    [CONFIGURATIONS <config>...]
    [COMPONENT <component>]
    [NAMELINK_COMPONENT <component>]
    [OPTIONAL] [EXCLUDE_FROM_ALL]
    [NAMELINK_ONLY|NAMELINK_SKIP]

  The first ``<artifact-option>...`` group applies to target
  :ref:`Output Artifacts` that do not have a dedicated group specified
  later in the same call.

  .. _`<artifact-kind>`:

  Each ``<artifact-kind> <artifact-option>...`` group applies to
  :ref:`Output Artifacts` of the specified artifact kind:

  ``ARCHIVE``
    Target artifacts of this kind include:

    * *Static libraries*
      (except on macOS when marked as ``FRAMEWORK``, see below);
    * *DLL import libraries*
      (on all Windows-based systems including Cygwin; they have extension
      ``.lib``, in contrast to the ``.dll`` libraries that go to ``RUNTIME``);
    * On AIX, the *linker import file* created for executables with
      :prop_tgt:`ENABLE_EXPORTS` enabled.
    * On macOS, the *linker import file* created for shared libraries with
      :prop_tgt:`ENABLE_EXPORTS` enabled (except when marked as ``FRAMEWORK``,
      see below).

  ``LIBRARY``
    Target artifacts of this kind include:

    * *Shared libraries*, except

      - DLLs (these go to ``RUNTIME``, see below),
      - on macOS when marked as ``FRAMEWORK`` (see below).

  ``RUNTIME``
    Target artifacts of this kind include:

    * *Executables*
      (except on macOS when marked as ``MACOSX_BUNDLE``, see ``BUNDLE`` below);
    * DLLs (on all Windows-based systems including Cygwin; note that the
      accompanying import libraries are of kind ``ARCHIVE``).

  ``OBJECTS``
    .. versionadded:: 3.9

    Object files associated with *object libraries*.

  ``FRAMEWORK``
    Both static and shared libraries marked with the ``FRAMEWORK``
    property are treated as ``FRAMEWORK`` targets on macOS.

  ``BUNDLE``
    Executables marked with the :prop_tgt:`MACOSX_BUNDLE` property are treated as
    ``BUNDLE`` targets on macOS.

  ``PUBLIC_HEADER``
    Any :prop_tgt:`PUBLIC_HEADER` files associated with a library are installed in
    the destination specified by the ``PUBLIC_HEADER`` argument on non-Apple
    platforms. Rules defined by this argument are ignored for :prop_tgt:`FRAMEWORK`
    libraries on Apple platforms because the associated files are installed
    into the appropriate locations inside the framework folder. See
    :prop_tgt:`PUBLIC_HEADER` for details.

  ``PRIVATE_HEADER``
    Similar to ``PUBLIC_HEADER``, but for ``PRIVATE_HEADER`` files. See
    :prop_tgt:`PRIVATE_HEADER` for details.

  ``RESOURCE``
    Similar to ``PUBLIC_HEADER`` and ``PRIVATE_HEADER``, but for
    ``RESOURCE`` files. See :prop_tgt:`RESOURCE` for details.

  ``FILE_SET <set-name>``
    .. versionadded:: 3.23

    File sets are defined by the :command:`target_sources(FILE_SET)` command.
    If the file set ``<set-name>`` exists and is ``PUBLIC`` or ``INTERFACE``,
    any files in the set are installed under the destination (see below).
    The directory structure relative to the file set's base directories is
    preserved. For example, a file added to the file set as
    ``/blah/include/myproj/here.h`` with a base directory ``/blah/include``
    would be installed to ``myproj/here.h`` below the destination.

  ``CXX_MODULES_BMI``
    .. versionadded:: 3.28

    Any module files from C++ modules from ``PUBLIC`` sources in a file set of
    type ``CXX_MODULES`` will be installed to the given ``DESTINATION``. All
    modules are placed directly in the destination as no directory structure is
    derived from the names of the modules. An empty ``DESTINATION`` may be used
    to suppress installing these files (for use in generic code).

  For regular executables, static libraries and shared libraries, the
  ``DESTINATION`` argument is not required.  For these target types, when
  ``DESTINATION`` is omitted, a default destination will be taken from the
  appropriate variable from :module:`GNUInstallDirs`, or set to a built-in
  default value if that variable is not defined.  The same is true for file
  sets, and the public and private headers associated with the installed
  targets through the :prop_tgt:`PUBLIC_HEADER` and :prop_tgt:`PRIVATE_HEADER`
  target properties. A destination must always be provided for module libraries,
  Apple bundles and frameworks.  A destination can be omitted for interface and
  object libraries, but they are handled differently (see the discussion of this
  topic toward the end of this section).

  For shared libraries on DLL platforms, if neither ``RUNTIME`` nor ``ARCHIVE``
  destinations are specified, both the ``RUNTIME`` and ``ARCHIVE`` components are
  installed to their default destinations. If either a ``RUNTIME`` or ``ARCHIVE``
  destination is specified, the component is installed to that destination, and
  the other component is not installed. If both ``RUNTIME`` and ``ARCHIVE``
  destinations are specified, then both components are installed to their
  respective destinations.

  The following table shows the target types with their associated variables and
  built-in defaults that apply when no destination is given:

  =============================== =============================== ======================
     Target Type                      GNUInstallDirs Variable        Built-In Default
  =============================== =============================== ======================
  ``RUNTIME``                     ``${CMAKE_INSTALL_BINDIR}``     ``bin``
  ``LIBRARY``                     ``${CMAKE_INSTALL_LIBDIR}``     ``lib``
  ``ARCHIVE``                     ``${CMAKE_INSTALL_LIBDIR}``     ``lib``
  ``PRIVATE_HEADER``              ``${CMAKE_INSTALL_INCLUDEDIR}`` ``include``
  ``PUBLIC_HEADER``               ``${CMAKE_INSTALL_INCLUDEDIR}`` ``include``
  ``FILE_SET`` (type ``HEADERS``) ``${CMAKE_INSTALL_INCLUDEDIR}`` ``include``
  =============================== =============================== ======================

  Projects wishing to follow the common practice of installing headers into a
  project-specific subdirectory may prefer using file sets with appropriate
  paths and base directories. Otherwise, they must provide a ``DESTINATION``
  instead of being able to rely on the above (see next example below).

  To make packages compliant with distribution filesystem layout policies, if
  projects must specify a ``DESTINATION``, it is strongly recommended that they use
  a path that begins with the appropriate relative :module:`GNUInstallDirs` variable.
  This allows package maintainers to control the install destination by setting
  the appropriate cache variables.  The following example shows a static library
  being installed to the default destination provided by
  :module:`GNUInstallDirs`, but with its headers installed to a project-specific
  subdirectory without using file sets:

  .. code-block:: cmake

    add_library(mylib STATIC ...)
    set_target_properties(mylib PROPERTIES PUBLIC_HEADER mylib.h)
    include(GNUInstallDirs)
    install(TARGETS mylib
            PUBLIC_HEADER
              DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/myproj
    )

  In addition to the `common options`_ listed above, each target can accept
  the following additional arguments:

  ``NAMELINK_COMPONENT``
    .. versionadded:: 3.12

    On some platforms a versioned shared library has a symbolic link such
    as::

      lib<name>.so -> lib<name>.so.1

    where ``lib<name>.so.1`` is the soname of the library and ``lib<name>.so``
    is a "namelink" allowing linkers to find the library when given
    ``-l<name>``. The ``NAMELINK_COMPONENT`` option is similar to the
    ``COMPONENT`` option, but it changes the installation component of a shared
    library namelink if one is generated. If not specified, this defaults to the
    value of ``COMPONENT``. It is an error to use this parameter outside of a
    ``LIBRARY`` block.

    .. versionchanged:: 3.27
      This parameter is also usable for an ``ARCHIVE`` block to manage
      the linker import file created, on macOS, for shared libraries with
      :prop_tgt:`ENABLE_EXPORTS` enabled.

    See the `Example: Install Targets with Per-Artifact Components`_
    for an example using ``NAMELINK_COMPONENT``.

    This option is typically used for package managers that have separate
    runtime and development packages. For example, on Debian systems, the
    library is expected to be in the runtime package, and the headers and
    namelink are expected to be in the development package.

    See the :prop_tgt:`VERSION` and :prop_tgt:`SOVERSION` target properties for
    details on creating versioned shared libraries.

  ``NAMELINK_ONLY``
    This option causes the installation of only the namelink when a library
    target is installed. On platforms where versioned shared libraries do not
    have namelinks or when a library is not versioned, the ``NAMELINK_ONLY``
    option installs nothing. It is an error to use this parameter outside of a
    ``LIBRARY`` block.

    .. versionchanged:: 3.27
      This parameter is also usable for an ``ARCHIVE`` block to manage
      the linker import file created, on macOS, for shared libraries with
      :prop_tgt:`ENABLE_EXPORTS` enabled.

    When ``NAMELINK_ONLY`` is given, either ``NAMELINK_COMPONENT`` or
    ``COMPONENT`` may be used to specify the installation component of the
    namelink, but ``COMPONENT`` should generally be preferred.

  ``NAMELINK_SKIP``
    Similar to ``NAMELINK_ONLY``, but it has the opposite effect: it causes the
    installation of library files other than the namelink when a library target
    is installed. When neither ``NAMELINK_ONLY`` or ``NAMELINK_SKIP`` are given,
    both portions are installed. On platforms where versioned shared libraries
    do not have symlinks or when a library is not versioned, ``NAMELINK_SKIP``
    installs the library. It is an error to use this parameter outside of a
    ``LIBRARY`` block.

    .. versionchanged:: 3.27
      This parameter is also usable for an ``ARCHIVE`` block to manage
      the linker import file created, on macOS, for shared libraries with
      :prop_tgt:`ENABLE_EXPORTS` enabled.

    If ``NAMELINK_SKIP`` is specified, ``NAMELINK_COMPONENT`` has no effect. It
    is not recommended to use ``NAMELINK_SKIP`` in conjunction with
    ``NAMELINK_COMPONENT``.

  The :command:`install(TARGETS)` command can also accept the following
  options at the top level:

  ``EXPORT``
    This option associates the installed target files with an export called
    ``<export-name>``.  It must appear before any target options.
    To actually install the export file itself, call
    :command:`install(EXPORT)`, documented below.
    See documentation of the :prop_tgt:`EXPORT_NAME` target property to change
    the name of the exported target.

    If ``EXPORT`` is used and the targets include ``PUBLIC`` or ``INTERFACE``
    file sets, all of them must be specified with ``FILE_SET`` arguments. All
    ``PUBLIC`` or ``INTERFACE`` file sets associated with a target are included
    in the export.

  ``INCLUDES DESTINATION``
    This option specifies a list of directories which will be added to the
    :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` target property of the
    ``<targets>`` when exported by the :command:`install(EXPORT)` command.
    If a relative path is specified, it is treated as relative to the
    :genex:`$<INSTALL_PREFIX>`.

  ``RUNTIME_DEPENDENCY_SET <set-name>``
    .. versionadded:: 3.21

    This option causes all runtime dependencies of installed executable, shared
    library, and module targets to be added to the specified runtime dependency
    set. This set can then be installed with an
    :command:`install(RUNTIME_DEPENDENCY_SET)` command.

    This keyword and the ``RUNTIME_DEPENDENCIES`` keyword are mutually
    exclusive.

  ``RUNTIME_DEPENDENCIES <arg>...``
    .. versionadded:: 3.21

    This option causes all runtime dependencies of installed executable, shared
    library, and module targets to be installed along with the targets
    themselves. The ``RUNTIME``, ``LIBRARY``, ``FRAMEWORK``, and generic
    arguments are used to determine the properties (``DESTINATION``,
    ``COMPONENT``, etc.) of the installation of these dependencies.

    ``RUNTIME_DEPENDENCIES`` is semantically equivalent to the following pair
    of calls:

    .. code-block:: cmake

      install(TARGETS ... RUNTIME_DEPENDENCY_SET <set-name>)
      install(RUNTIME_DEPENDENCY_SET <set-name> <arg>...)

    where ``<set-name>`` will be a randomly generated set name.
    ``<arg>...`` may include any of the following keywords supported by
    the :command:`install(RUNTIME_DEPENDENCY_SET)` command:

    * ``DIRECTORIES``
    * ``PRE_INCLUDE_REGEXES``
    * ``PRE_EXCLUDE_REGEXES``
    * ``POST_INCLUDE_REGEXES``
    * ``POST_EXCLUDE_REGEXES``
    * ``POST_INCLUDE_FILES``
    * ``POST_EXCLUDE_FILES``

    The ``RUNTIME_DEPENDENCIES`` and ``RUNTIME_DEPENDENCY_SET`` keywords are
    mutually exclusive.

  :ref:`Interface Libraries` may be listed among the targets to install.
  They install no artifacts but will be included in an associated ``EXPORT``.
  If :ref:`Object Libraries` are listed but given no destination for their
  object files, they will be exported as :ref:`Interface Libraries`.
  This is sufficient to satisfy transitive usage requirements of other
  targets that link to the object libraries in their implementation.

  Installing a target with the :prop_tgt:`EXCLUDE_FROM_ALL` target property
  set to ``TRUE`` has undefined behavior.

  .. versionadded:: 3.3
    An install destination given as a ``DESTINATION`` argument may
    use "generator expressions" with the syntax ``$<...>``.  See the
    :manual:`cmake-generator-expressions(7)` manual for available expressions.

  .. versionadded:: 3.13
    :command:`install(TARGETS)` can install targets that were created in
    other directories.  When using such cross-directory install rules, running
    ``make install`` (or similar) from a subdirectory will not guarantee that
    targets from other directories are up-to-date.  You can use
    :command:`target_link_libraries` or :command:`add_dependencies`
    to ensure that such out-of-directory targets are built before the
    subdirectory-specific install rules are run.

.. signature::
  install(IMPORTED_RUNTIME_ARTIFACTS <target>... [...])

  .. versionadded:: 3.21

  Install runtime artifacts of imported targets:

  .. code-block:: cmake

    install(IMPORTED_RUNTIME_ARTIFACTS <target>...
            [RUNTIME_DEPENDENCY_SET <set-name>]
            [[LIBRARY|RUNTIME|FRAMEWORK|BUNDLE]
             [DESTINATION <dir>]
             [PERMISSIONS <permission>...]
             [CONFIGURATIONS <config>...]
             [COMPONENT <component>]
             [OPTIONAL] [EXCLUDE_FROM_ALL]
            ] [...]
            )

  The ``IMPORTED_RUNTIME_ARTIFACTS`` form specifies rules for installing the
  runtime artifacts of imported targets. Projects may do this if they want to
  bundle outside executables or modules inside their installation. The
  ``LIBRARY``, ``RUNTIME``, ``FRAMEWORK``, and ``BUNDLE`` arguments have the
  same semantics that they do in the `TARGETS`_ mode. Only the runtime artifacts
  of imported targets are installed (except in the case of :prop_tgt:`FRAMEWORK`
  libraries, :prop_tgt:`MACOSX_BUNDLE` executables, and :prop_tgt:`BUNDLE`
  CFBundles.) For example, headers and import libraries associated with DLLs are
  not installed. In the case of :prop_tgt:`FRAMEWORK` libraries,
  :prop_tgt:`MACOSX_BUNDLE` executables, and :prop_tgt:`BUNDLE` CFBundles, the
  entire directory is installed.

  The ``RUNTIME_DEPENDENCY_SET`` option causes the runtime artifacts of the
  imported executable, shared library, and module library ``targets`` to be
  added to the ``<set-name>`` runtime dependency set. This set can then be
  installed with an :command:`install(RUNTIME_DEPENDENCY_SET)` command.

.. signature::
  install(FILES <file>... [...])
  install(PROGRAMS <program>... [...])

  .. note::

    If installing header files, consider using file sets defined by
    :command:`target_sources(FILE_SET)` instead. File sets associate
    headers with a target and they install as part of the target.

  Install files or programs:

  .. code-block:: cmake

    install(<FILES|PROGRAMS> <file>...
            TYPE <type> | DESTINATION <dir>
            [PERMISSIONS <permission>...]
            [CONFIGURATIONS <config>...]
            [COMPONENT <component>]
            [RENAME <name>] [OPTIONAL] [EXCLUDE_FROM_ALL])

  The ``FILES`` form specifies rules for installing files for a project.
  File names given as relative paths are interpreted with respect to the
  current source directory.  Files installed by this form are by default
  given permissions ``OWNER_WRITE``, ``OWNER_READ``, ``GROUP_READ``, and
  ``WORLD_READ`` if no ``PERMISSIONS`` argument is given.

  The ``PROGRAMS`` form is identical to the ``FILES`` form except that the
  default permissions for the installed file also include ``OWNER_EXECUTE``,
  ``GROUP_EXECUTE``, and ``WORLD_EXECUTE``.  This form is intended to install
  programs that are not targets, such as shell scripts.  Use the ``TARGETS``
  form to install targets built within the project.

  The list of ``files...`` given to ``FILES`` or ``PROGRAMS`` may use
  "generator expressions" with the syntax ``$<...>``.  See the
  :manual:`cmake-generator-expressions(7)` manual for available expressions.
  However, if any item begins in a generator expression it must evaluate
  to a full path.

  Either a ``TYPE`` or a ``DESTINATION`` must be provided, but not both.
  A ``TYPE`` argument specifies the generic file type of the files being
  installed.  A destination will then be set automatically by taking the
  corresponding variable from :module:`GNUInstallDirs`, or by using a
  built-in default if that variable is not defined.  See the table below for
  the supported file types and their corresponding variables and built-in
  defaults.  Projects can provide a ``DESTINATION`` argument instead of a
  file type if they wish to explicitly define the install destination.

  ======================= ================================== =========================
     ``TYPE`` Argument         GNUInstallDirs Variable           Built-In Default
  ======================= ================================== =========================
  ``BIN``                 ``${CMAKE_INSTALL_BINDIR}``        ``bin``
  ``SBIN``                ``${CMAKE_INSTALL_SBINDIR}``       ``sbin``
  ``LIB``                 ``${CMAKE_INSTALL_LIBDIR}``        ``lib``
  ``INCLUDE``             ``${CMAKE_INSTALL_INCLUDEDIR}``    ``include``
  ``SYSCONF``             ``${CMAKE_INSTALL_SYSCONFDIR}``    ``etc``
  ``SHAREDSTATE``         ``${CMAKE_INSTALL_SHARESTATEDIR}`` ``com``
  ``LOCALSTATE``          ``${CMAKE_INSTALL_LOCALSTATEDIR}`` ``var``
  ``RUNSTATE``            ``${CMAKE_INSTALL_RUNSTATEDIR}``   ``<LOCALSTATE dir>/run``
  ``DATA``                ``${CMAKE_INSTALL_DATADIR}``       ``<DATAROOT dir>``
  ``INFO``                ``${CMAKE_INSTALL_INFODIR}``       ``<DATAROOT dir>/info``
  ``LOCALE``              ``${CMAKE_INSTALL_LOCALEDIR}``     ``<DATAROOT dir>/locale``
  ``MAN``                 ``${CMAKE_INSTALL_MANDIR}``        ``<DATAROOT dir>/man``
  ``DOC``                 ``${CMAKE_INSTALL_DOCDIR}``        ``<DATAROOT dir>/doc``
  ======================= ================================== =========================

  Projects wishing to follow the common practice of installing headers into a
  project-specific subdirectory will need to provide a destination rather than
  rely on the above. Using file sets for headers instead of ``install(FILES)``
  would be even better (see :command:`target_sources(FILE_SET)`).

  Note that some of the types' built-in defaults use the ``DATAROOT`` directory as
  a prefix. The ``DATAROOT`` prefix is calculated similarly to the types, with
  ``CMAKE_INSTALL_DATAROOTDIR`` as the variable and ``share`` as the built-in
  default. You cannot use ``DATAROOT`` as a ``TYPE`` parameter; please use
  ``DATA`` instead.

  To make packages compliant with distribution filesystem layout policies, if
  projects must specify a ``DESTINATION``, it is strongly recommended that they use
  a path that begins with the appropriate relative :module:`GNUInstallDirs` variable.
  This allows package maintainers to control the install destination by setting
  the appropriate cache variables.  The following example shows how to follow
  this advice while installing an image to a project-specific documentation
  subdirectory:

  .. code-block:: cmake

    include(GNUInstallDirs)
    install(FILES logo.png
            DESTINATION ${CMAKE_INSTALL_DOCDIR}/myproj
    )

  .. versionadded:: 3.4
    An install destination given as a ``DESTINATION`` argument may
    use "generator expressions" with the syntax ``$<...>``.  See the
    :manual:`cmake-generator-expressions(7)` manual for available expressions.

  .. versionadded:: 3.20
    An install rename given as a ``RENAME`` argument may
    use "generator expressions" with the syntax ``$<...>``.  See the
    :manual:`cmake-generator-expressions(7)` manual for available expressions.

.. signature::
  install(DIRECTORY <dir>... [...])

  .. note::

    To install a directory sub-tree of headers, consider using file sets
    defined by :command:`target_sources(FILE_SET)` instead. File sets not only
    preserve directory structure, they also associate headers with a target
    and install as part of the target.

  Install the contents of one or more directories:

  .. code-block:: cmake

    install(DIRECTORY dirs...
            TYPE <type> | DESTINATION <dir>
            [FILE_PERMISSIONS <permission>...]
            [DIRECTORY_PERMISSIONS <permission>...]
            [USE_SOURCE_PERMISSIONS] [OPTIONAL] [MESSAGE_NEVER]
            [CONFIGURATIONS <config>...]
            [COMPONENT <component>] [EXCLUDE_FROM_ALL]
            [FILES_MATCHING]
            [[PATTERN <pattern> | REGEX <regex>]
             [EXCLUDE] [PERMISSIONS <permission>...]] [...])

  The ``DIRECTORY`` form installs contents of one or more directories to a
  given destination.  The directory structure is copied verbatim to the
  destination.  The last component of each directory name is appended to
  the destination directory but a trailing slash may be used to avoid
  this because it leaves the last component empty.  Directory names
  given as relative paths are interpreted with respect to the current
  source directory.  If no input directory names are given the
  destination directory will be created but nothing will be installed
  into it.  The ``FILE_PERMISSIONS`` and ``DIRECTORY_PERMISSIONS`` options
  specify permissions given to files and directories in the destination.
  If ``USE_SOURCE_PERMISSIONS`` is specified and ``FILE_PERMISSIONS`` is not,
  file permissions will be copied from the source directory structure.
  If no permissions are specified files will be given the default
  permissions specified in the ``FILES`` form of the command, and the
  directories will be given the default permissions specified in the
  ``PROGRAMS`` form of the command.

  .. versionadded:: 3.1
    The ``MESSAGE_NEVER`` option disables file installation status output.

  Installation of directories may be controlled with fine granularity
  using the ``PATTERN`` or ``REGEX`` options.  These "match" options specify a
  globbing pattern or regular expression to match directories or files
  encountered within input directories.  They may be used to apply
  certain options (see below) to a subset of the files and directories
  encountered.  The full path to each input file or directory (with
  forward slashes) is matched against the expression.  A ``PATTERN`` will
  match only complete file names: the portion of the full path matching
  the pattern must occur at the end of the file name and be preceded by
  a slash.  A ``REGEX`` will match any portion of the full path but it may
  use ``/`` and ``$`` to simulate the ``PATTERN`` behavior.  By default all
  files and directories are installed whether or not they are matched.
  The ``FILES_MATCHING`` option may be given before the first match option
  to disable installation of files (but not directories) not matched by
  any expression.  For example, the code

  .. code-block:: cmake

    install(DIRECTORY src/ DESTINATION doc/myproj
            FILES_MATCHING PATTERN "*.png")

  will extract and install images from a source tree.

  Some options may follow a ``PATTERN`` or ``REGEX`` expression as described
  under :ref:`string(REGEX) <Regex Specification>` and are applied
  only to files or directories matching them.  The ``EXCLUDE`` option will
  skip the matched file or directory.  The ``PERMISSIONS`` option overrides
  the permissions setting for the matched file or directory.  For
  example the code

  .. code-block:: cmake

    install(DIRECTORY icons scripts/ DESTINATION share/myproj
            PATTERN "CVS" EXCLUDE
            PATTERN "scripts/*"
            PERMISSIONS OWNER_EXECUTE OWNER_WRITE OWNER_READ
                        GROUP_EXECUTE GROUP_READ)

  will install the ``icons`` directory to ``share/myproj/icons`` and the
  ``scripts`` directory to ``share/myproj``.  The icons will get default
  file permissions, the scripts will be given specific permissions, and any
  ``CVS`` directories will be excluded.

  Either a ``TYPE`` or a ``DESTINATION`` must be provided, but not both.
  A ``TYPE`` argument specifies the generic file type of the files within the
  listed directories being installed.  A destination will then be set
  automatically by taking the corresponding variable from
  :module:`GNUInstallDirs`, or by using a built-in default if that variable
  is not defined.  See the table below for the supported file types and their
  corresponding variables and built-in defaults.  Projects can provide a
  ``DESTINATION`` argument instead of a file type if they wish to explicitly
  define the install destination.

  ======================= ================================== =========================
     ``TYPE`` Argument         GNUInstallDirs Variable           Built-In Default
  ======================= ================================== =========================
  ``BIN``                 ``${CMAKE_INSTALL_BINDIR}``        ``bin``
  ``SBIN``                ``${CMAKE_INSTALL_SBINDIR}``       ``sbin``
  ``LIB``                 ``${CMAKE_INSTALL_LIBDIR}``        ``lib``
  ``INCLUDE``             ``${CMAKE_INSTALL_INCLUDEDIR}``    ``include``
  ``SYSCONF``             ``${CMAKE_INSTALL_SYSCONFDIR}``    ``etc``
  ``SHAREDSTATE``         ``${CMAKE_INSTALL_SHARESTATEDIR}`` ``com``
  ``LOCALSTATE``          ``${CMAKE_INSTALL_LOCALSTATEDIR}`` ``var``
  ``RUNSTATE``            ``${CMAKE_INSTALL_RUNSTATEDIR}``   ``<LOCALSTATE dir>/run``
  ``DATA``                ``${CMAKE_INSTALL_DATADIR}``       ``<DATAROOT dir>``
  ``INFO``                ``${CMAKE_INSTALL_INFODIR}``       ``<DATAROOT dir>/info``
  ``LOCALE``              ``${CMAKE_INSTALL_LOCALEDIR}``     ``<DATAROOT dir>/locale``
  ``MAN``                 ``${CMAKE_INSTALL_MANDIR}``        ``<DATAROOT dir>/man``
  ``DOC``                 ``${CMAKE_INSTALL_DOCDIR}``        ``<DATAROOT dir>/doc``
  ======================= ================================== =========================

  Note that some of the types' built-in defaults use the ``DATAROOT`` directory as
  a prefix. The ``DATAROOT`` prefix is calculated similarly to the types, with
  ``CMAKE_INSTALL_DATAROOTDIR`` as the variable and ``share`` as the built-in
  default. You cannot use ``DATAROOT`` as a ``TYPE`` parameter; please use
  ``DATA`` instead.

  To make packages compliant with distribution filesystem layout policies, if
  projects must specify a ``DESTINATION``, it is strongly recommended that they use
  a path that begins with the appropriate relative :module:`GNUInstallDirs` variable.
  This allows package maintainers to control the install destination by setting
  the appropriate cache variables.

  .. versionadded:: 3.4
    An install destination given as a ``DESTINATION`` argument may
    use "generator expressions" with the syntax ``$<...>``.  See the
    :manual:`cmake-generator-expressions(7)` manual for available expressions.

  .. versionadded:: 3.5
    The list of ``dirs...`` given to ``DIRECTORY`` may use
    "generator expressions" too.

.. signature::
  install(SCRIPT <file> [...])
  install(CODE <code> [...])

  Invoke CMake scripts or code during installation:

  .. code-block:: cmake

    install([[SCRIPT <file>] [CODE <code>]]
            [ALL_COMPONENTS | COMPONENT <component>]
            [EXCLUDE_FROM_ALL] [...])

  The ``SCRIPT`` form will invoke the given CMake script files during
  installation.  If the script file name is a relative path it will be
  interpreted with respect to the current source directory.  The ``CODE``
  form will invoke the given CMake code during installation.  Code is
  specified as a single argument inside a double-quoted string.  For
  example, the code

  .. code-block:: cmake

    install(CODE "MESSAGE(\"Sample install message.\")")

  will print a message during installation.

  .. versionadded:: 3.21
    When the ``ALL_COMPONENTS`` option is given, the custom installation
    script code will be executed for every component of a component-specific
    installation.  This option is mutually exclusive with the ``COMPONENT``
    option.

  .. versionadded:: 3.14
    ``<file>`` or ``<code>`` may use "generator expressions" with the syntax
    ``$<...>`` (in the case of ``<file>``, this refers to their use in the file
    name, not the file's contents).  See the
    :manual:`cmake-generator-expressions(7)` manual for available expressions.

.. signature::
  install(EXPORT <export-name> [...])

  Install a CMake file exporting targets for dependent projects:

  .. code-block:: cmake

    install(EXPORT <export-name> DESTINATION <dir>
            [NAMESPACE <namespace>] [FILE <name>.cmake]
            [PERMISSIONS <permission>...]
            [CONFIGURATIONS <config>...]
            [CXX_MODULES_DIRECTORY <directory>]
            [EXPORT_LINK_INTERFACE_LIBRARIES]
            [COMPONENT <component>]
            [EXCLUDE_FROM_ALL]
            [EXPORT_PACKAGE_DEPENDENCIES])
    install(EXPORT_ANDROID_MK <export-name> DESTINATION <dir> [...])

  The ``EXPORT`` form generates and installs a CMake file containing code to
  import targets from the installation tree into another project.
  Target installations are associated with the export ``<export-name>``
  using the ``EXPORT`` option of the :command:`install(TARGETS)` signature
  documented above.  The ``NAMESPACE`` option will prepend ``<namespace>`` to
  the target names as they are written to the import file.  By default
  the generated file will be called ``<export-name>.cmake`` but the ``FILE``
  option may be used to specify a different name.  The value given to
  the ``FILE`` option must be a file name with the ``.cmake`` extension.
  If a ``CONFIGURATIONS`` option is given then the file will only be installed
  when one of the named configurations is installed.  Additionally, the
  generated import file will reference only the matching target
  configurations.  See the :variable:`CMAKE_MAP_IMPORTED_CONFIG_<CONFIG>`
  variable to map configurations of dependent projects to the installed
  configurations.  The ``EXPORT_LINK_INTERFACE_LIBRARIES`` keyword, if
  present, causes the contents of the properties matching
  ``(IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?`` to be exported, when
  policy :policy:`CMP0022` is ``NEW``.

  .. note::
    The installed ``<export-name>.cmake`` file may come with additional
    per-configuration ``<export-name>-*.cmake`` files to be loaded by
    globbing.  Do not use an export name that is the same as the package
    name in combination with installing a ``<package-name>-config.cmake``
    file or the latter may be incorrectly matched by the glob and loaded.

  When a ``COMPONENT`` option is given, the listed ``<component>`` implicitly
  depends on all components mentioned in the export set. The exported
  ``<name>.cmake`` file will require each of the exported components to be
  present in order for dependent projects to build properly. For example, a
  project may define components ``Runtime`` and ``Development``, with shared
  libraries going into the ``Runtime`` component and static libraries and
  headers going into the ``Development`` component. The export set would also
  typically be part of the ``Development`` component, but it would export
  targets from both the ``Runtime`` and ``Development`` components. Therefore,
  the ``Runtime`` component would need to be installed if the ``Development``
  component was installed, but not vice versa. If the ``Development`` component
  was installed without the ``Runtime`` component, dependent projects that try
  to link against it would have build errors. Package managers, such as APT and
  RPM, typically handle this by listing the ``Runtime`` component as a dependency
  of the ``Development`` component in the package metadata, ensuring that the
  library is always installed if the headers and CMake export file are present.

  .. versionadded:: 3.7
    In addition to cmake language files, the ``EXPORT_ANDROID_MK`` mode may be
    used to specify an export to the android ndk build system.  This mode
    accepts the same options as the normal export mode.  The Android
    NDK supports the use of prebuilt libraries, both static and shared. This
    allows cmake to build the libraries of a project and make them available
    to an ndk build system complete with transitive dependencies, include flags
    and defines required to use the libraries.

  ``CXX_MODULES_DIRECTORY``
    .. versionadded:: 3.28

    Specify a subdirectory to store C++ module information for targets in the
    export set. This directory will be populated with files which add the
    necessary target property information to the relevant targets. Note that
    without this information, none of the C++ modules which are part of the
    targets in the export set will support being imported in consuming targets.

  ``EXPORT_PACKAGE_DEPENDENCIES``
    .. versionadded:: 3.29

    Specify that :command:`find_dependency` calls should be exported. If this
    argument is specified, CMake examines all targets in the export set and
    gathers their ``INTERFACE`` link targets. If any such targets either were
    found with :command:`find_package` or have the
    :prop_tgt:`EXPORT_FIND_PACKAGE_NAME` property set, and such package
    dependency was not disabled by passing ``ENABLED OFF`` to
    :command:`export(SETUP)`, then a :command:`find_dependency` call is
    written with the target's corresponding package name, a ``REQUIRED``
    argument, and any additional arguments specified by the ``EXTRA_ARGS``
    argument of :command:`export(SETUP)`. Any package dependencies that were
    manually specified by passing ``ENABLED ON`` to :command:`export(SETUP)`
    are also added, even if the exported targets don't depend on any targets
    from them.

    The :command:`find_dependency` calls are written in the following order:

    1. Any package dependencies that were listed in :command:`export(SETUP)`
       are written in the order they were first specified, regardless of
       whether or not they contain ``INTERFACE`` dependencies of the
       exported targets.
    2. Any package dependencies that contain ``INTERFACE`` link dependencies
       of the exported targets and that were never specified in
       :command:`export(SETUP)` are written in the order they were first
       found.

  The ``EXPORT`` form is useful to help outside projects use targets built
  and installed by the current project.  For example, the code

  .. code-block:: cmake

    install(TARGETS myexe EXPORT myproj DESTINATION bin)
    install(EXPORT myproj NAMESPACE mp_ DESTINATION lib/myproj)
    install(EXPORT_ANDROID_MK myproj DESTINATION share/ndk-modules)

  will install the executable ``myexe`` to ``<prefix>/bin`` and code to import
  it in the file ``<prefix>/lib/myproj/myproj.cmake`` and
  ``<prefix>/share/ndk-modules/Android.mk``.  An outside project
  may load this file with the include command and reference the ``myexe``
  executable from the installation tree using the imported target name
  ``mp_myexe`` as if the target were built in its own tree.

  .. note::
    This command supersedes the :command:`install_targets` command and
    the :prop_tgt:`PRE_INSTALL_SCRIPT` and :prop_tgt:`POST_INSTALL_SCRIPT`
    target properties.  It also replaces the ``FILES`` forms of the
    :command:`install_files` and :command:`install_programs` commands.
    The processing order of these install rules relative to
    those generated by :command:`install_targets`,
    :command:`install_files`, and :command:`install_programs` commands
    is not defined.

.. signature::
  install(RUNTIME_DEPENDENCY_SET <set-name> [...])

  .. versionadded:: 3.21

  Installs a runtime dependency set:

  .. code-block:: cmake

    install(RUNTIME_DEPENDENCY_SET <set-name>
            [[LIBRARY|RUNTIME|FRAMEWORK]
             [DESTINATION <dir>]
             [PERMISSIONS <permission>...]
             [CONFIGURATIONS <config>...]
             [COMPONENT <component>]
             [NAMELINK_COMPONENT <component>]
             [OPTIONAL] [EXCLUDE_FROM_ALL]
            ] [...]
            [PRE_INCLUDE_REGEXES <regex>...]
            [PRE_EXCLUDE_REGEXES <regex>...]
            [POST_INCLUDE_REGEXES <regex>...]
            [POST_EXCLUDE_REGEXES <regex>...]
            [POST_INCLUDE_FILES <file>...]
            [POST_EXCLUDE_FILES <file>...]
            [DIRECTORIES <dir>...]
            )

  Installs a runtime dependency set previously created by one or more
  :command:`install(TARGETS)` or :command:`install(IMPORTED_RUNTIME_ARTIFACTS)`
  commands.  The dependencies of targets belonging to a runtime dependency set
  are installed in the ``RUNTIME`` destination and component on DLL platforms,
  and in the ``LIBRARY`` destination and component on non-DLL platforms.
  macOS frameworks are installed in the ``FRAMEWORK`` destination and component.
  Targets built within the build tree will never be installed as runtime
  dependencies, nor will their own dependencies, unless the targets themselves
  are installed with :command:`install(TARGETS)`.

  The generated install script calls :command:`file(GET_RUNTIME_DEPENDENCIES)`
  on the build-tree files to calculate the runtime dependencies. The build-tree
  executable files are passed as the ``EXECUTABLES`` argument, the build-tree
  shared libraries as the ``LIBRARIES`` argument, and the build-tree modules as
  the ``MODULES`` argument. On macOS, if one of the executables is a
  :prop_tgt:`MACOSX_BUNDLE`, that executable is passed as the
  ``BUNDLE_EXECUTABLE`` argument. At most one such bundle executable may be in
  the runtime dependency set on macOS. The :prop_tgt:`MACOSX_BUNDLE` property
  has no effect on other platforms. Note that
  :command:`file(GET_RUNTIME_DEPENDENCIES)` only supports collecting the runtime
  dependencies for Windows, Linux and macOS platforms, so
  ``install(RUNTIME_DEPENDENCY_SET)`` has the same limitation.

  The following sub-arguments are forwarded through as the corresponding
  arguments to :command:`file(GET_RUNTIME_DEPENDENCIES)` (for those that provide
  a non-empty list of directories, regular expressions or files).  They all
  support :manual:`generator expressions <cmake-generator-expressions(7)>`.

  * ``DIRECTORIES <dir>...``
  * ``PRE_INCLUDE_REGEXES <regex>...``
  * ``PRE_EXCLUDE_REGEXES <regex>...``
  * ``POST_INCLUDE_REGEXES <regex>...``
  * ``POST_EXCLUDE_REGEXES <regex>...``
  * ``POST_INCLUDE_FILES <file>...``
  * ``POST_EXCLUDE_FILES <file>...``

Examples
^^^^^^^^

Example: Install Targets with Per-Artifact Components
"""""""""""""""""""""""""""""""""""""""""""""""""""""

Consider a project that defines targets with different artifact kinds:

.. code-block:: cmake

  add_executable(myExe myExe.c)
  add_library(myStaticLib STATIC myStaticLib.c)
  target_sources(myStaticLib PUBLIC FILE_SET HEADERS FILES myStaticLib.h)
  add_library(mySharedLib SHARED mySharedLib.c)
  target_sources(mySharedLib PUBLIC FILE_SET HEADERS FILES mySharedLib.h)
  set_property(TARGET mySharedLib PROPERTY SOVERSION 1)

We may call :command:`install(TARGETS)` with `\<artifact-kind\>`_ arguments
to specify different options for each kind of artifact:

.. code-block:: cmake

  install(TARGETS
            myExe
            mySharedLib
            myStaticLib
          RUNTIME           # Following options apply to runtime artifacts.
            COMPONENT Runtime
          LIBRARY           # Following options apply to library artifacts.
            COMPONENT Runtime
            NAMELINK_COMPONENT Development
          ARCHIVE           # Following options apply to archive artifacts.
            COMPONENT Development
            DESTINATION lib/static
          FILE_SET HEADERS  # Following options apply to file set HEADERS.
            COMPONENT Development
          )

This will:

* Install ``myExe`` to ``<prefix>/bin``, the default RUNTIME artifact
  destination, as part of the ``Runtime`` component.

* On non-DLL platforms:

  * Install ``libmySharedLib.so.1`` to ``<prefix>/lib``, the default
    LIBRARY artifact destination, as part of the ``Runtime`` component.

  * Install the ``libmySharedLib.so`` "namelink" (symbolic link) to
    ``<prefix>/lib``, the default LIBRARY artifact destination, as part
    of the ``Development`` component.

* On DLL platforms:

  * Install ``mySharedLib.dll`` to ``<prefix>/bin``, the default RUNTIME
    artifact destination, as part of the ``Runtime`` component.

  * Install ``mySharedLib.lib`` to ``<prefix>/lib/static``, the specified
    ARCHIVE artifact destination, as part of the ``Development`` component.

* Install ``myStaticLib`` to ``<prefix>/lib/static``, the specified
  ARCHIVE artifact destination, as part of the ``Development`` component.

* Install ``mySharedLib.h`` and ``myStaticLib.h`` to ``<prefix>/include``,
  the default destination for a file set of type HEADERS, as part of the
  ``Development`` component.

Example: Install Targets to Per-Config Destinations
"""""""""""""""""""""""""""""""""""""""""""""""""""

Each :command:`install(TARGETS)` call installs a given target
:ref:`output artifact <Output Artifacts>` to at most one ``DESTINATION``,
but the install rule itself may be filtered by the ``CONFIGURATIONS`` option.
In order to install to a different destination for each configuration, one
call per configuration is needed.  For example, the code:

.. code-block:: cmake

  install(TARGETS myExe
          CONFIGURATIONS Debug
          RUNTIME
            DESTINATION Debug/bin
          )
  install(TARGETS myExe
          CONFIGURATIONS Release
          RUNTIME
            DESTINATION Release/bin
          )

will install ``myExe`` to ``<prefix>/Debug/bin`` in the Debug configuration,
and to ``<prefix>/Release/bin`` in the Release configuration.

Generated Installation Script
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. note::

  Use of this feature is not recommended. Please consider using the
  :option:`cmake --install` instead.

The ``install()`` command generates a file, ``cmake_install.cmake``, inside
the build directory, which is used internally by the generated install target
and by CPack. You can also invoke this script manually with
:option:`cmake -P`. This script accepts several variables:

``COMPONENT``
  Set this variable to install only a single CPack component as opposed to all
  of them. For example, if you only want to install the ``Development``
  component, run ``cmake -DCOMPONENT=Development -P cmake_install.cmake``.

``BUILD_TYPE``
  Set this variable to change the build type if you are using a multi-config
  generator. For example, to install with the ``Debug`` configuration, run
  ``cmake -DBUILD_TYPE=Debug -P cmake_install.cmake``.

``DESTDIR``
  This is an environment variable rather than a CMake variable. It allows you
  to change the installation prefix on UNIX systems. See :envvar:`DESTDIR` for
  details.


code:
install_files
-------------

.. deprecated:: 3.0

  Use the :command:`install(FILES)` command instead.

This command has been superseded by the :command:`install` command.  It is
provided for compatibility with older CMake code.  The ``FILES`` form is
directly replaced by the ``FILES`` form of the :command:`install`
command.  The regexp form can be expressed more clearly using the ``GLOB``
form of the :command:`file` command.

.. code-block:: cmake

  install_files(<dir> extension file file ...)

Create rules to install the listed files with the given extension into
the given directory.  Only files existing in the current source tree
or its corresponding location in the binary tree may be listed.  If a
file specified already has an extension, that extension will be
removed first.  This is useful for providing lists of source files
such as foo.cxx when you want the corresponding foo.h to be installed.
A typical extension is ``.h``.

.. code-block:: cmake

  install_files(<dir> regexp)

Any files in the current source directory that match the regular
expression will be installed.

.. code-block:: cmake

  install_files(<dir> FILES file file ...)

Any files listed after the ``FILES`` keyword will be installed explicitly
from the names given.  Full paths are allowed in this form.

The directory ``<dir>`` is relative to the installation prefix, which is
stored in the variable :variable:`CMAKE_INSTALL_PREFIX`.

repo_name: lazytadpole/codenamesilverfish

license: mit


code:
install_programs
----------------

.. deprecated:: 3.0

  Use the :command:`install(PROGRAMS)` command instead.

This command has been superseded by the :command:`install` command.  It is
provided for compatibility with older CMake code.  The ``FILES`` form is
directly replaced by the ``PROGRAMS`` form of the :command:`install`
command.  The regexp form can be expressed more clearly using the ``GLOB``
form of the :command:`file` command.

.. code-block:: cmake

  install_programs(<dir> file1 file2 [file3 ...])
  install_programs(<dir> FILES file1 [file2 ...])

Create rules to install the listed programs into the given directory.
Use the ``FILES`` argument to guarantee that the file list version of the
command will be used even when there is only one argument.

.. code-block:: cmake

  install_programs(<dir> regexp)

In the second form any program in the current source directory that
matches the regular expression will be installed.

This command is intended to install programs that are not built by
cmake, such as shell scripts.  See the ``TARGETS`` form of the
:command:`install` command to create installation rules for targets built
by cmake.

The directory ``<dir>`` is relative to the installation prefix, which is
stored in the variable :variable:`CMAKE_INSTALL_PREFIX`.


code:
install_targets
---------------

.. deprecated:: 3.0

  Use the :command:`install(TARGETS)` command instead.

This command has been superseded by the :command:`install` command.  It is
provided for compatibility with older CMake code.

.. code-block:: cmake

  install_targets(<dir> [RUNTIME_DIRECTORY dir] target target)

Create rules to install the listed targets into the given directory.
The directory ``<dir>`` is relative to the installation prefix, which is
stored in the variable :variable:`CMAKE_INSTALL_PREFIX`.  If
``RUNTIME_DIRECTORY`` is specified, then on systems with special runtime
files (Windows DLL), the files will be copied to that directory.


code:
link_directories
----------------

Add directories in which the linker will look for libraries.

.. code-block:: cmake

  link_directories([AFTER|BEFORE] directory1 [directory2 ...])

Adds the paths in which the linker should search for libraries.
Relative paths given to this command are interpreted as relative to
the current source directory, see :policy:`CMP0015`.

The command will apply only to targets created after it is called.

.. versionadded:: 3.13
  The directories are added to the :prop_dir:`LINK_DIRECTORIES` directory
  property for the current ``CMakeLists.txt`` file, converting relative
  paths to absolute as needed.  See the :manual:`cmake-buildsystem(7)`
  manual for more on defining buildsystem properties.

.. versionadded:: 3.13
  By default the directories specified are appended onto the current list of
  directories.  This default behavior can be changed by setting
  :variable:`CMAKE_LINK_DIRECTORIES_BEFORE` to ``ON``.  By using
  ``AFTER`` or ``BEFORE`` explicitly, you can select between appending and
  prepending, independent of the default.

.. versionadded:: 3.13
  Arguments to ``link_directories`` may use "generator expressions" with
  the syntax "$<...>".  See the :manual:`cmake-generator-expressions(7)`
  manual for available expressions.

.. note::

  This command is rarely necessary and should be avoided where there are
  other choices.  Prefer to pass full absolute paths to libraries where
  possible, since this ensures the correct library will always be linked.
  The :command:`find_library` command provides the full path, which can
  generally be used directly in calls to :command:`target_link_libraries`.
  Situations where a library search path may be needed include:

  - Project generators like Xcode where the user can switch target
    architecture at build time, but a full path to a library cannot
    be used because it only provides one architecture (i.e. it is not
    a universal binary).
  - Libraries may themselves have other private library dependencies
    that expect to be found via ``RPATH`` mechanisms, but some linkers
    are not able to fully decode those paths (e.g. due to the presence
    of things like ``$ORIGIN``).

  If a library search path must be provided, prefer to localize the effect
  where possible by using the :command:`target_link_directories` command
  rather than ``link_directories()``.  The target-specific command can also
  control how the search directories propagate to other dependent targets.

See Also
^^^^^^^^

* :command:`target_link_directories`
* :command:`target_link_libraries`


code:
link_libraries
--------------

Link libraries to all targets added later.

.. code-block:: cmake

  link_libraries([item1 [item2 [...]]]
                 [[debug|optimized|general] <item>] ...)

Specify libraries or flags to use when linking any targets created later in
the current directory or below by commands such as :command:`add_executable`
or :command:`add_library`.  See the :command:`target_link_libraries` command
for meaning of arguments.

.. note::
  The :command:`target_link_libraries` command should be preferred whenever
  possible.  Library dependencies are chained automatically, so directory-wide
  specification of link libraries is rarely needed.


code:
list
----

Operations on :ref:`semicolon-separated lists <CMake Language Lists>`.

Synopsis
^^^^^^^^

.. parsed-literal::

  `Reading`_
    list(`LENGTH`_ <list> <out-var>)
    list(`GET`_ <list> <element index> [<index> ...] <out-var>)
    list(`JOIN`_ <list> <glue> <out-var>)
    list(`SUBLIST`_ <list> <begin> <length> <out-var>)

  `Search`_
    list(`FIND`_ <list> <value> <out-var>)

  `Modification`_
    list(`APPEND`_ <list> [<element>...])
    list(`FILTER`_ <list> {INCLUDE | EXCLUDE} REGEX <regex>)
    list(`INSERT`_ <list> <index> [<element>...])
    list(`POP_BACK`_ <list> [<out-var>...])
    list(`POP_FRONT`_ <list> [<out-var>...])
    list(`PREPEND`_ <list> [<element>...])
    list(`REMOVE_ITEM`_ <list> <value>...)
    list(`REMOVE_AT`_ <list> <index>...)
    list(`REMOVE_DUPLICATES`_ <list>)
    list(`TRANSFORM`_ <list> <ACTION> [...])

  `Ordering`_
    list(`REVERSE`_ <list>)
    list(`SORT`_ <list> [...])

Introduction
^^^^^^^^^^^^

The list subcommands :cref:`APPEND`, :cref:`INSERT`, :cref:`FILTER`,
:cref:`PREPEND`, :cref:`POP_BACK`, :cref:`POP_FRONT`, :cref:`REMOVE_AT`,
:cref:`REMOVE_ITEM`, :cref:`REMOVE_DUPLICATES`, :cref:`REVERSE` and
:cref:`SORT` may create new values for the list within the current CMake
variable scope.  Similar to the :command:`set` command, the ``list`` command
creates new variable values in the current scope, even if the list itself is
actually defined in a parent scope.  To propagate the results of these
operations upwards, use :command:`set` with ``PARENT_SCOPE``,
:command:`set` with ``CACHE INTERNAL``, or some other means of value
propagation.

.. note::

  A list in cmake is a ``;`` separated group of strings.  To create a
  list, the :command:`set` command can be used.  For example,
  ``set(var a b c d e)`` creates a list with ``a;b;c;d;e``, and
  ``set(var "a b c d e")`` creates a string or a list with one item in it.
  (Note that macro arguments are not variables, and therefore cannot be used
  in ``LIST`` commands.)

  Individual elements may not contain an unequal number of ``[`` and ``]``
  characters, and may not end in a backslash (``\``).
  See :ref:`semicolon-separated lists <CMake Language Lists>` for details.

.. note::

  When specifying index values, if ``<element index>`` is 0 or greater, it
  is indexed from the beginning of the list, with 0 representing the
  first list element.  If ``<element index>`` is -1 or lesser, it is indexed
  from the end of the list, with -1 representing the last list element.
  Be careful when counting with negative indices: they do not start from
  0.  -0 is equivalent to 0, the first list element.

Reading
^^^^^^^

.. signature::
  list(LENGTH <list> <output variable>)

  Returns the list's length.

.. signature::
  list(GET <list> <element index> [<element index> ...] <output variable>)

  Returns the list of elements specified by indices from the list.

.. signature:: list(JOIN <list> <glue> <output variable>)

  .. versionadded:: 3.12

  Returns a string joining all list's elements using the glue string.
  To join multiple strings, which are not part of a list,
  use :command:`string(JOIN)`.

.. signature::
  list(SUBLIST <list> <begin> <length> <output variable>)

  .. versionadded:: 3.12

  Returns a sublist of the given list.
  If ``<length>`` is 0, an empty list will be returned.
  If ``<length>`` is -1 or the list is smaller than ``<begin>+<length>`` then
  the remaining elements of the list starting at ``<begin>`` will be returned.

Search
^^^^^^

.. signature::
  list(FIND <list> <value> <output variable>)

  Returns the index of the element specified in the list
  or ``-1`` if it wasn't found.

Modification
^^^^^^^^^^^^

.. signature::
  list(APPEND <list> [<element> ...])

  Appends elements to the list. If no variable named ``<list>`` exists in the
  current scope its value is treated as empty and the elements are appended to
  that empty list.

.. signature::
  list(FILTER <list> <INCLUDE|EXCLUDE> REGEX <regular_expression>)

.. versionadded:: 3.6

Includes or removes items from the list that match the mode's pattern.
In ``REGEX`` mode, items will be matched against the given regular expression.

For more information on regular expressions look under
:ref:`string(REGEX) <Regex Specification>`.

.. signature::
  list(INSERT <list> <element_index> <element> [<element> ...])

  Inserts elements to the list to the specified index. It is an
  error to specify an out-of-range index. Valid indexes are 0 to `N`
  where `N` is the length of the list, inclusive. An empty list
  has length 0. If no variable named ``<list>`` exists in the
  current scope its value is treated as empty and the elements are
  inserted in that empty list.

.. signature::
  list(POP_BACK <list> [<out-var>...])

  .. versionadded:: 3.15

  If no variable name is given, removes exactly one element. Otherwise,
  with `N` variable names provided, assign the last `N` elements' values
  to the given variables and then remove the last `N` values from
  ``<list>``.

.. signature::
  list(POP_FRONT <list> [<out-var>...])

  .. versionadded:: 3.15

  If no variable name is given, removes exactly one element. Otherwise,
  with `N` variable names provided, assign the first `N` elements' values
  to the given variables and then remove the first `N` values from
  ``<list>``.

.. signature::
  list(PREPEND <list> [<element> ...])

  .. versionadded:: 3.15

  Insert elements to the 0th position in the list. If no variable named
  ``<list>`` exists in the current scope its value is treated as empty and
  the elements are prepended to that empty list.

.. signature::
  list(REMOVE_ITEM <list> <value> [<value> ...])

  Removes all instances of the given items from the list.

.. signature::
  list(REMOVE_AT <list> <index> [<index> ...])

  Removes items at given indices from the list.

.. signature::
  list(REMOVE_DUPLICATES <list>)

  Removes duplicated items in the list. The relative order of items
  is preserved, but if duplicates are encountered,
  only the first instance is preserved.

.. signature::
  list(TRANSFORM <list> <ACTION> [<SELECTOR>]
       [OUTPUT_VARIABLE <output variable>])

  .. versionadded:: 3.12

  Transforms the list by applying an ``<ACTION>`` to all or, by specifying a
  ``<SELECTOR>``, to the selected elements of the list, storing the result
  in-place or in the specified output variable.

  .. note::

    The ``TRANSFORM`` sub-command does not change the number of elements in the
    list. If a ``<SELECTOR>`` is specified, only some elements will be changed,
    the other ones will remain the same as before the transformation.

  ``<ACTION>`` specifies the action to apply to the elements of the list.
  The actions have exactly the same semantics as sub-commands of the
  :command:`string` command.  ``<ACTION>`` must be one of the following:

    :command:`APPEND <string(APPEND)>`, :command:`PREPEND <string(PREPEND)>`
      Append, prepend specified value to each element of the list.

      .. signature::
        list(TRANSFORM <list> (APPEND|PREPEND) <value> ...)
        :target: TRANSFORM_APPEND

    :command:`TOLOWER <string(TOLOWER)>`, :command:`TOUPPER <string(TOUPPER)>`
      Convert each element of the list to lower, upper characters.

      .. signature::
        list(TRANSFORM <list> (TOLOWER|TOUPPER) ...)
        :target: TRANSFORM_TOLOWER

    :command:`STRIP <string(STRIP)>`
      Remove leading and trailing spaces from each element of the list.

      .. signature::
        list(TRANSFORM <list> STRIP ...)
        :target: TRANSFORM_STRIP

    :command:`GENEX_STRIP <string(GENEX_STRIP)>`
      Strip any
      :manual:`generator expressions <cmake-generator-expressions(7)>`
      from each element of the list.

      .. signature::
        list(TRANSFORM <list> GENEX_STRIP ...)
        :target: TRANSFORM_GENEX_STRIP

    :command:`REPLACE <string(REGEX REPLACE)>`:
      Match the regular expression as many times as possible and substitute
      the replacement expression for the match for each element of the list
      (same semantic as :command:`string(REGEX REPLACE)`).

      .. signature::
        list(TRANSFORM <list> REPLACE <regular_expression>
                                      <replace_expression> ...)
        :target: TRANSFORM_REPLACE

  ``<SELECTOR>`` determines which elements of the list will be transformed.
  Only one type of selector can be specified at a time.
  When given, ``<SELECTOR>`` must be one of the following:

    ``AT``
      Specify a list of indexes.

      .. code-block:: cmake

        list(TRANSFORM <list> <ACTION> AT <index> [<index> ...] ...)

    ``FOR``
      Specify a range with, optionally,
      an increment used to iterate over the range.

      .. code-block:: cmake

        list(TRANSFORM <list> <ACTION> FOR <start> <stop> [<step>] ...)

    ``REGEX``
      Specify a regular expression.
      Only elements matching the regular expression will be transformed.

      .. code-block:: cmake

        list(TRANSFORM <list> <ACTION> REGEX <regular_expression> ...)

Ordering
^^^^^^^^

.. signature::
  list(REVERSE <list>)

  Reverses the contents of the list in-place.

.. signature::
  list(SORT <list> [COMPARE <compare>] [CASE <case>] [ORDER <order>])

  Sorts the list in-place alphabetically.

  .. versionadded:: 3.13
    Added the ``COMPARE``, ``CASE``, and ``ORDER`` options.

  .. versionadded:: 3.18
    Added the ``COMPARE NATURAL`` option.

  Use the ``COMPARE`` keyword to select the comparison method for sorting.
  The ``<compare>`` option should be one of:

    ``STRING``
      Sorts a list of strings alphabetically.
      This is the default behavior if the ``COMPARE`` option is not given.

    ``FILE_BASENAME``
      Sorts a list of pathnames of files by their basenames.

    ``NATURAL``
      Sorts a list of strings using natural order
      (see ``strverscmp(3)`` manual), i.e. such that contiguous digits
      are compared as whole numbers.
      For example: the following list `10.0 1.1 2.1 8.0 2.0 3.1`
      will be sorted as `1.1 2.0 2.1 3.1 8.0 10.0` if the ``NATURAL``
      comparison is selected where it will be sorted as
      `1.1 10.0 2.0 2.1 3.1 8.0` with the ``STRING`` comparison.

  Use the ``CASE`` keyword to select a case sensitive or case insensitive
  sort mode.  The ``<case>`` option should be one of:

    ``SENSITIVE``
      List items are sorted in a case-sensitive manner.
      This is the default behavior if the ``CASE`` option is not given.

    ``INSENSITIVE``
      List items are sorted case insensitively.  The order of
      items which differ only by upper/lowercase is not specified.

  To control the sort order, the ``ORDER`` keyword can be given.
  The ``<order>`` option should be one of:

    ``ASCENDING``
      Sorts the list in ascending order.
      This is the default behavior when the ``ORDER`` option is not given.

    ``DESCENDING``
      Sorts the list in descending order.


code:
load_cache
----------

Load in the values from another project's CMake cache.

.. code-block:: cmake

  load_cache(pathToBuildDirectory READ_WITH_PREFIX prefix entry1...)

Reads the cache and store the requested entries in variables with their
name prefixed with the given prefix.  This only reads the values, and
does not create entries in the local project's cache.

.. code-block:: cmake

  load_cache(pathToBuildDirectory [EXCLUDE entry1...]
             [INCLUDE_INTERNALS entry1...])

Loads in the values from another cache and store them in the local
project's cache as internal entries.  This is useful for a project
that depends on another project built in a different tree.  ``EXCLUDE``
option can be used to provide a list of entries to be excluded.
``INCLUDE_INTERNALS`` can be used to provide a list of internal entries to
be included.  Normally, no internal entries are brought in.  Use of
this form of the command is strongly discouraged, but it is provided
for backward compatibility.


code:
load_command
------------

Disallowed since version 3.0.  See CMake Policy :policy:`CMP0031`.

Load a command into a running CMake.

.. code-block:: cmake

  load_command(COMMAND_NAME <loc1> [loc2 ...])

The given locations are searched for a library whose name is
cmCOMMAND_NAME.  If found, it is loaded as a module and the command is
added to the set of available CMake commands.  Usually,
:command:`try_compile` is used before this command to compile the
module.  If the command is successfully loaded a variable named

.. code-block:: cmake

  CMAKE_LOADED_COMMAND_<COMMAND_NAME>

will be set to the full path of the module that was loaded.  Otherwise
the variable will not be set.


code:
macro
-----

Start recording a macro for later invocation as a command

.. code-block:: cmake

  macro(<name> [<arg1> ...])
    <commands>
  endmacro()

Defines a macro named ``<name>`` that takes arguments named
``<arg1>``, ... Commands listed after macro, but before the
matching :command:`endmacro()`, are not executed until the macro
is invoked.

Per legacy, the :command:`endmacro` command admits an optional
``<name>`` argument. If used, it must be a verbatim repeat of the
argument of the opening ``macro`` command.

See the :command:`cmake_policy()` command documentation for the behavior
of policies inside macros.

See the :ref:`Macro vs Function` section below for differences
between CMake macros and :command:`functions <function>`.

Invocation
^^^^^^^^^^

The macro invocation is case-insensitive. A macro defined as

.. code-block:: cmake

  macro(foo)
    <commands>
  endmacro()

can be invoked through any of

.. code-block:: cmake

  foo()
  Foo()
  FOO()
  cmake_language(CALL foo)

and so on. However, it is strongly recommended to stay with the
case chosen in the macro definition.  Typically macros use
all-lowercase names.

.. versionadded:: 3.18
  The :command:`cmake_language(CALL ...)` command can also be used to
  invoke the macro.

Arguments
^^^^^^^^^

When a macro is invoked, the commands recorded in the macro are
first modified by replacing formal parameters (``${arg1}``, ...)
with the arguments passed, and then invoked as normal commands.

In addition to referencing the formal parameters you can reference the
values ``${ARGC}`` which will be set to the number of arguments passed
into the function as well as ``${ARGV0}``, ``${ARGV1}``, ``${ARGV2}``,
...  which will have the actual values of the arguments passed in.
This facilitates creating macros with optional arguments.

Furthermore, ``${ARGV}`` holds the list of all arguments given to the
macro and ``${ARGN}`` holds the list of arguments past the last expected
argument.
Referencing to ``${ARGV#}`` arguments beyond ``${ARGC}`` have undefined
behavior. Checking that ``${ARGC}`` is greater than ``#`` is the only
way to ensure that ``${ARGV#}`` was passed to the function as an extra
argument.

.. _`Macro vs Function`:

Macro vs Function
^^^^^^^^^^^^^^^^^

The ``macro`` command is very similar to the :command:`function` command.
Nonetheless, there are a few important differences.

In a function, ``ARGN``, ``ARGC``, ``ARGV`` and ``ARGV0``, ``ARGV1``, ...
are true variables in the usual CMake sense.  In a macro, they are not,
they are string replacements much like the C preprocessor would do
with a macro.  This has a number of consequences, as explained in
the :ref:`Argument Caveats` section below.

Another difference between macros and functions is the control flow.
A function is executed by transferring control from the calling
statement to the function body.  A macro is executed as if the macro
body were pasted in place of the calling statement.  This has the
consequence that a :command:`return()` in a macro body does not
just terminate execution of the macro; rather, control is returned
from the scope of the macro call.  To avoid confusion, it is recommended
to avoid :command:`return()` in macros altogether.

Unlike a function, the :variable:`CMAKE_CURRENT_FUNCTION`,
:variable:`CMAKE_CURRENT_FUNCTION_LIST_DIR`,
:variable:`CMAKE_CURRENT_FUNCTION_LIST_FILE`,
:variable:`CMAKE_CURRENT_FUNCTION_LIST_LINE` variables are not
set for a macro.

.. _`Argument Caveats`:

Argument Caveats
^^^^^^^^^^^^^^^^

Since ``ARGN``, ``ARGC``, ``ARGV``, ``ARGV0`` etc. are not variables,
you will NOT be able to use commands like

.. code-block:: cmake

 if(ARGV1) # ARGV1 is not a variable
 if(DEFINED ARGV2) # ARGV2 is not a variable
 if(ARGC GREATER 2) # ARGC is not a variable
 foreach(loop_var IN LISTS ARGN) # ARGN is not a variable

In the first case, you can use ``if(${ARGV1})``.  In the second and
third case, the proper way to check if an optional variable was
passed to the macro is to use ``if(${ARGC} GREATER 2)``.  In the
last case, you can use ``foreach(loop_var ${ARGN})`` but this will
skip empty arguments.  If you need to include them, you can use

.. code-block:: cmake

 set(list_var "${ARGN}")
 foreach(loop_var IN LISTS list_var)

Note that if you have a variable with the same name in the scope from
which the macro is called, using unreferenced names will use the
existing variable instead of the arguments. For example:

.. code-block:: cmake

 macro(bar)
   foreach(arg IN LISTS ARGN)
     <commands>
   endforeach()
 endmacro()

 function(foo)
   bar(x y z)
 endfunction()

 foo(a b c)

Will loop over ``a;b;c`` and not over ``x;y;z`` as one might have expected.
If you want true CMake variables and/or better CMake scope control you
should look at the function command.

See Also
^^^^^^^^

* :command:`cmake_parse_arguments`
* :command:`endmacro`


code:
make_directory
--------------

.. deprecated:: 3.0

  Use the :command:`file(MAKE_DIRECTORY)` command instead.

.. code-block:: cmake

  make_directory(directory)

Creates the specified directory.  Full paths should be given.  Any
parent directories that do not exist will also be created.  Use with
care.


code:
mark_as_advanced
----------------

Mark cmake cached variables as advanced.

.. code-block:: cmake

  mark_as_advanced([CLEAR|FORCE] <var1> ...)

Sets the advanced/non-advanced state of the named
cached variables.

An advanced variable will not be displayed in any
of the cmake GUIs unless the ``show advanced`` option is on.
In script mode, the advanced/non-advanced state has no effect.

If the keyword ``CLEAR`` is given
then advanced variables are changed back to unadvanced.
If the keyword ``FORCE`` is given
then the variables are made advanced.
If neither ``FORCE`` nor ``CLEAR`` is specified,
new values will be marked as advanced, but if a
variable already has an advanced/non-advanced state,
it will not be changed.

.. versionchanged:: 3.17
  Variables passed to this command which are not already in the cache
  are ignored. See policy :policy:`CMP0102`.


code:
math
----

Evaluate a mathematical expression.

.. code-block:: cmake

  math(EXPR <variable> "<expression>" [OUTPUT_FORMAT <format>])

Evaluates a mathematical ``<expression>`` and sets ``<variable>`` to the
resulting value.  The result of the expression must be representable as a
64-bit signed integer. Floating point inputs are invalid e.g. ``1.1 * 10``.
Non-integer results e.g. ``3 / 2`` are truncated.

The mathematical expression must be given as a string (i.e. enclosed in
double quotation marks). An example is ``"5 * (10 + 13)"``.
Supported operators are ``+``, ``-``, ``*``, ``/``, ``%``, ``|``, ``&``,
``^``, ``~``, ``<<``, ``>>``, and ``(...)``; they have the same meaning
as in C code.

.. versionadded:: 3.13
  Hexadecimal numbers are recognized when prefixed with ``0x``, as in C code.

.. versionadded:: 3.13
  The result is formatted according to the option ``OUTPUT_FORMAT``,
  where ``<format>`` is one of

  ``HEXADECIMAL``
    Hexadecimal notation as in C code, i. e. starting with "0x".
  ``DECIMAL``
    Decimal notation. Which is also used if no ``OUTPUT_FORMAT`` option
    is specified.

For example

.. code-block:: cmake

  math(EXPR value "100 * 0xA" OUTPUT_FORMAT DECIMAL)      # value is set to "1000"
  math(EXPR value "100 * 0xA" OUTPUT_FORMAT HEXADECIMAL)  # value is set to "0x3e8"


code:
message
-------

Log a message.

Synopsis
^^^^^^^^

.. parsed-literal::

  `General messages`_
    message([<mode>] "message text" ...)

  `Reporting checks`_
    message(<checkState> "message text" ...)

  `Configure Log`_
    message(CONFIGURE_LOG <text>...)

General messages
^^^^^^^^^^^^^^^^

.. code-block:: cmake

  message([<mode>] "message text" ...)

Record the specified message text in the log.  If more than one message
string is given, they are concatenated into a single message with no
separator between the strings.

The optional ``<mode>`` keyword determines the type of message, which
influences the way the message is handled:

``FATAL_ERROR``
  CMake Error, stop processing and generation.

  The :manual:`cmake(1)` executable will return a non-zero
  :ref:`exit code <CMake Exit Code>`.

``SEND_ERROR``
  CMake Error, continue processing, but skip generation.

``WARNING``
  CMake Warning, continue processing.

``AUTHOR_WARNING``
  CMake Warning (dev), continue processing.

``DEPRECATION``
  CMake Deprecation Error or Warning if variable
  :variable:`CMAKE_ERROR_DEPRECATED` or :variable:`CMAKE_WARN_DEPRECATED`
  is enabled, respectively, else no message.

(none) or ``NOTICE``
  Important message printed to stderr to attract user's attention.

``STATUS``
  The main interesting messages that project users might be interested in.
  Ideally these should be concise, no more than a single line, but still
  informative.

``VERBOSE``
  Detailed informational messages intended for project users.  These messages
  should provide additional details that won't be of interest in most cases,
  but which may be useful to those building the project when they want deeper
  insight into what's happening.

``DEBUG``
  Detailed informational messages intended for developers working on the
  project itself as opposed to users who just want to build it.  These messages
  will not typically be of interest to other users building the project and
  will often be closely related to internal implementation details.

``TRACE``
  Fine-grained messages with very low-level implementation details.  Messages
  using this log level would normally only be temporary and would expect to be
  removed before releasing the project, packaging up the files, etc.

.. versionadded:: 3.15
  Added the ``NOTICE``, ``VERBOSE``, ``DEBUG``, and ``TRACE`` levels.

The CMake command-line tool displays ``STATUS`` to ``TRACE`` messages on stdout
with the message preceded by two hyphens and a space.  All other message types
are sent to stderr and are not prefixed with hyphens.  The
:manual:`CMake GUI <cmake-gui(1)>` displays all messages in its log area.
The :manual:`curses interface <ccmake(1)>` shows ``STATUS`` to ``TRACE``
messages one at a time on a status line and other messages in an
interactive pop-up box.  The :option:`--log-level <cmake --log-level>`
command-line option to each of these tools can be used to control which
messages will be shown.

.. versionadded:: 3.17
  To make a log level persist between CMake runs, the
  :variable:`CMAKE_MESSAGE_LOG_LEVEL` variable can be set instead.
  Note that the command line option takes precedence over the cache variable.

.. versionadded:: 3.16
  Messages of log levels ``NOTICE`` and below will have each line preceded
  by the content of the :variable:`CMAKE_MESSAGE_INDENT` variable (converted to
  a single string by concatenating its list items).  For ``STATUS`` to ``TRACE``
  messages, this indenting content will be inserted after the hyphens.

.. versionadded:: 3.17
  Messages of log levels ``NOTICE`` and below can also have each line preceded
  with context of the form ``[some.context.example]``.  The content between the
  square brackets is obtained by converting the :variable:`CMAKE_MESSAGE_CONTEXT`
  list variable to a dot-separated string.  The message context will always
  appear before any indenting content but after any automatically added leading
  hyphens. By default, message context is not shown, it has to be explicitly
  enabled by giving the :option:`cmake --log-context`
  command-line option or by setting the :variable:`CMAKE_MESSAGE_CONTEXT_SHOW`
  variable to true.  See the :variable:`CMAKE_MESSAGE_CONTEXT` documentation for
  usage examples.

CMake Warning and Error message text displays using a simple markup
language.  Non-indented text is formatted in line-wrapped paragraphs
delimited by newlines.  Indented text is considered pre-formatted.

Reporting checks
^^^^^^^^^^^^^^^^

.. versionadded:: 3.17

A common pattern in CMake output is a message indicating the start of some
sort of check, followed by another message reporting the result of that check.
For example:

.. code-block:: cmake

  message(STATUS "Looking for someheader.h")
  #... do the checks, set checkSuccess with the result
  if(checkSuccess)
    message(STATUS "Looking for someheader.h - found")
  else()
    message(STATUS "Looking for someheader.h - not found")
  endif()

This can be more robustly and conveniently expressed using the ``CHECK_...``
keyword form of the ``message()`` command:

.. code-block:: cmake

  message(<checkState> "message" ...)

where ``<checkState>`` must be one of the following:

  ``CHECK_START``
    Record a concise message about the check about to be performed.

  ``CHECK_PASS``
    Record a successful result for a check.

  ``CHECK_FAIL``
    Record an unsuccessful result for a check.

When recording a check result, the command repeats the message from the most
recently started check for which no result has yet been reported, then some
separator characters and then the message text provided after the
``CHECK_PASS`` or ``CHECK_FAIL`` keyword.  Check messages are always reported
at ``STATUS`` log level.

Checks may be nested and every ``CHECK_START`` should have exactly one
matching ``CHECK_PASS`` or ``CHECK_FAIL``.
The :variable:`CMAKE_MESSAGE_INDENT` variable can also be used to add
indenting to nested checks if desired.  For example:

.. code-block:: cmake

  message(CHECK_START "Finding my things")
  list(APPEND CMAKE_MESSAGE_INDENT "  ")
  unset(missingComponents)

  message(CHECK_START "Finding partA")
  # ... do check, assume we find A
  message(CHECK_PASS "found")

  message(CHECK_START "Finding partB")
  # ... do check, assume we don't find B
  list(APPEND missingComponents B)
  message(CHECK_FAIL "not found")

  list(POP_BACK CMAKE_MESSAGE_INDENT)
  if(missingComponents)
    message(CHECK_FAIL "missing components: ${missingComponents}")
  else()
    message(CHECK_PASS "all components found")
  endif()

Output from the above would appear something like the following::

  -- Finding my things
  --   Finding partA
  --   Finding partA - found
  --   Finding partB
  --   Finding partB - not found
  -- Finding my things - missing components: B

Configure Log
^^^^^^^^^^^^^

.. versionadded:: 3.26

.. code-block:: cmake

  message(CONFIGURE_LOG <text>...)

Record a :ref:`configure-log message event <message configure-log event>`
with the specified ``<text>``.  By convention, if the text contains more
than one line, the first line should be a summary of the event.

This mode is intended to record the details of a system inspection check
or other one-time operation guarded by a cache entry, but that is not
performed using :command:`try_compile` or :command:`try_run`, which
automatically log their details.  Projects should avoid calling it every
time CMake runs.  For example:

.. code-block:: cmake

  if (NOT DEFINED MY_CHECK_RESULT)
    # Print check summary in configure output.
    message(CHECK_START "My Check")

    # ... perform system inspection, e.g., with execute_process ...

    # Cache the result so we do not run the check again.
    set(MY_CHECK_RESULT "${MY_CHECK_RESULT}" CACHE INTERNAL "My Check")

    # Record the check details in the cmake-configure-log.
    message(CONFIGURE_LOG
      "My Check Result: ${MY_CHECK_RESULT}\n"
      "${details}"
    )

    # Print check result in configure output.
    if(MY_CHECK_RESULT)
      message(CHECK_PASS "passed")
    else()
      message(CHECK_FAIL "failed")
    endif()
  endif()

If no project is currently being configured, such as in
:ref:`cmake -P <Script Processing Mode>` script mode,
this command does nothing.

See Also
^^^^^^^^

* :command:`cmake_language(GET_MESSAGE_LOG_LEVEL)`


code:
option
------

Provide a boolean option that the user can optionally select.

.. code-block:: cmake

  option(<variable> "<help_text>" [value])

If no initial ``<value>`` is provided, boolean ``OFF`` is the default value.
If ``<variable>`` is already set as a normal or cache variable,
then the command does nothing (see policy :policy:`CMP0077`).

For options that depend on the values of other options, see
the module help for :module:`CMakeDependentOption`.

In CMake project mode, a boolean cache variable is created with the option
value. In CMake script mode, a boolean variable is set with the option value.


code:
output_required_files
---------------------

Disallowed since version 3.0.  See CMake Policy :policy:`CMP0032`.

Approximate C preprocessor dependency scanning.

This command exists only because ancient CMake versions provided it.
CMake handles preprocessor dependency scanning automatically using a
more advanced scanner.

.. code-block:: cmake

  output_required_files(srcfile outputfile)

Outputs a list of all the source files that are required by the
specified ``srcfile``.  This list is written into ``outputfile``.  This is
similar to writing out the dependencies for ``srcfile`` except that it
jumps from ``.h`` files into ``.cxx``, ``.c`` and ``.cpp`` files if possible.


code:
project
-------

Set the name of the project.

Synopsis
^^^^^^^^

.. code-block:: cmake

 project(<PROJECT-NAME> [<language-name>...])
 project(<PROJECT-NAME>
         [VERSION <major>[.<minor>[.<patch>[.<tweak>]]]]
         [DESCRIPTION <project-description-string>]
         [HOMEPAGE_URL <url-string>]
         [LANGUAGES <language-name>...])

Sets the name of the project, and stores it in the variable
:variable:`PROJECT_NAME`. When called from the top-level
``CMakeLists.txt`` also stores the project name in the
variable :variable:`CMAKE_PROJECT_NAME`.

Also sets the variables:

:variable:`PROJECT_SOURCE_DIR`, :variable:`<PROJECT-NAME>_SOURCE_DIR`
  Absolute path to the source directory for the project.

:variable:`PROJECT_BINARY_DIR`, :variable:`<PROJECT-NAME>_BINARY_DIR`
  Absolute path to the binary directory for the project.

:variable:`PROJECT_IS_TOP_LEVEL`, :variable:`<PROJECT-NAME>_IS_TOP_LEVEL`
  .. versionadded:: 3.21

  Boolean value indicating whether the project is top-level.

Further variables are set by the optional arguments described in the following.
If any of these arguments is not used, then the corresponding variables are
set to the empty string.

Options
^^^^^^^

The options are:

``VERSION <version>``
  Optional; may not be used unless policy :policy:`CMP0048` is
  set to ``NEW``.

  Takes a ``<version>`` argument composed of non-negative integer components,
  i.e. ``<major>[.<minor>[.<patch>[.<tweak>]]]``,
  and sets the variables

  * :variable:`PROJECT_VERSION`,
    :variable:`<PROJECT-NAME>_VERSION`
  * :variable:`PROJECT_VERSION_MAJOR`,
    :variable:`<PROJECT-NAME>_VERSION_MAJOR`
  * :variable:`PROJECT_VERSION_MINOR`,
    :variable:`<PROJECT-NAME>_VERSION_MINOR`
  * :variable:`PROJECT_VERSION_PATCH`,
    :variable:`<PROJECT-NAME>_VERSION_PATCH`
  * :variable:`PROJECT_VERSION_TWEAK`,
    :variable:`<PROJECT-NAME>_VERSION_TWEAK`.

  .. versionadded:: 3.12
    When the ``project()`` command is called from the top-level
    ``CMakeLists.txt``, then the version is also stored in the variable
    :variable:`CMAKE_PROJECT_VERSION`.

``DESCRIPTION <project-description-string>``
  .. versionadded:: 3.9

  Optional.
  Sets the variables

  * :variable:`PROJECT_DESCRIPTION`, :variable:`<PROJECT-NAME>_DESCRIPTION`

  to ``<project-description-string>``.
  It is recommended that this description is a relatively short string,
  usually no more than a few words.

  When the ``project()`` command is called from the top-level ``CMakeLists.txt``,
  then the description is also stored in the variable :variable:`CMAKE_PROJECT_DESCRIPTION`.

  .. versionadded:: 3.12
    Added the ``<PROJECT-NAME>_DESCRIPTION`` variable.

``HOMEPAGE_URL <url-string>``
  .. versionadded:: 3.12

  Optional.
  Sets the variables

  * :variable:`PROJECT_HOMEPAGE_URL`, :variable:`<PROJECT-NAME>_HOMEPAGE_URL`

  to ``<url-string>``, which should be the canonical home URL for the project.

  When the ``project()`` command is called from the top-level ``CMakeLists.txt``,
  then the URL also is stored in the variable :variable:`CMAKE_PROJECT_HOMEPAGE_URL`.

``LANGUAGES <language-name>...``
  Optional.
  Can also be specified without ``LANGUAGES`` keyword per the first, short signature.

  Selects which programming languages are needed to build the project.

.. include:: SUPPORTED_LANGUAGES.txt

By default ``C`` and ``CXX`` are enabled if no language options are given.
Specify language ``NONE``, or use the ``LANGUAGES`` keyword and list no languages,
to skip enabling any languages.

The variables set through the ``VERSION``, ``DESCRIPTION`` and ``HOMEPAGE_URL``
options are intended for use as default values in package metadata and documentation.

.. _`Code Injection`:

Code Injection
^^^^^^^^^^^^^^

A number of variables can be defined by the user to specify files to include
at different points during the execution of the ``project()`` command.
The following outlines the steps performed during a ``project()`` call:

* .. versionadded:: 3.15
    For every ``project()`` call regardless of the project
    name, include the file named by :variable:`CMAKE_PROJECT_INCLUDE_BEFORE`,
    if set.

* .. versionadded:: 3.17
    If the ``project()`` command specifies ``<PROJECT-NAME>`` as its project
    name, include the file named by
    :variable:`CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE_BEFORE`, if set.

* Set the various project-specific variables detailed in the `Synopsis`_
  and `Options`_ sections above.

* For the very first ``project()`` call only:

  * If :variable:`CMAKE_TOOLCHAIN_FILE` is set, read it at least once.
    It may be read multiple times and it may also be read again when
    enabling languages later (see below).

  * Set the variables describing the host and target platforms.
    Language-specific variables might or might not be set at this point.
    On the first run, the only language-specific variables that might be
    defined are those a toolchain file may have set. On subsequent runs,
    language-specific variables cached from a previous run may be set.

  * .. versionadded:: 3.24
      Include each file listed in :variable:`CMAKE_PROJECT_TOP_LEVEL_INCLUDES`,
      if set. The variable is ignored by CMake thereafter.

* Enable any languages specified in the call, or the default languages if
  none were provided. The toolchain file may be re-read when enabling a
  language for the first time.

* .. versionadded:: 3.15
    For every ``project()`` call regardless of the project
    name, include the file named by :variable:`CMAKE_PROJECT_INCLUDE`,
    if set.

* If the ``project()`` command specifies ``<PROJECT-NAME>`` as its project
  name, include the file named by
  :variable:`CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE`, if set.

Usage
^^^^^

The top-level ``CMakeLists.txt`` file for a project must contain a
literal, direct call to the ``project()`` command; loading one
through the :command:`include` command is not sufficient.  If no such
call exists, CMake will issue a warning and pretend there is a
``project(Project)`` at the top to enable the default languages
(``C`` and ``CXX``).

.. note::
  Call the ``project()`` command near the top of the top-level
  ``CMakeLists.txt``, but *after* calling :command:`cmake_minimum_required`.
  It is important to establish version and policy settings before invoking
  other commands whose behavior they may affect and for this reason the
  ``project()`` command will issue a warning if this order is not kept.
  See also policy :policy:`CMP0000`.


code:
qt_wrap_cpp
-----------

.. deprecated:: 3.14

  This command was originally added to support Qt 3 before the
  :command:`add_custom_command()` command was sufficiently mature.  The
  :module:`FindQt4` module provides the ``qt4_wrap_cpp()`` macro, which
  should be used instead for Qt 4 projects.  For projects using Qt 5 or
  later, use the equivalent macro provided by Qt itself (e.g. Qt 5 provides
  `qt5_wrap_cpp() <https://doc.qt.io/qt-5/qtcore-cmake-qt5-wrap-cpp.html>`_).

Manually create Qt Wrappers.

.. code-block:: cmake

  qt_wrap_cpp(resultingLibraryName DestName SourceLists ...)

Produces moc files for all the .h files listed in the SourceLists.  The
moc files will be added to the library using the ``DestName`` source list.

Consider updating the project to use the :prop_tgt:`AUTOMOC` target property
instead for a more automated way of invoking the ``moc`` tool.


code:
qt_wrap_ui
----------

.. deprecated:: 3.14

  This command was originally added to support Qt 3 before the
  :command:`add_custom_command()` command was sufficiently mature.  The
  :module:`FindQt4` module provides the ``qt4_wrap_ui()`` macro, which
  should be used instead for Qt 4 projects.  For projects using Qt 5 or
  later, use the equivalent macro provided by Qt itself (e.g. Qt 5 provides
  ``qt5_wrap_ui()``).

Manually create Qt user interfaces Wrappers.

.. code-block:: cmake

  qt_wrap_ui(resultingLibraryName HeadersDestName
             SourcesDestName SourceLists ...)

Produces .h and .cxx files for all the .ui files listed in the
``SourceLists``.  The .h files will be added to the library using the
``HeadersDestNamesource`` list.  The .cxx files will be added to the
library using the ``SourcesDestNamesource`` list.

Consider updating the project to use the :prop_tgt:`AUTOUIC` target property
instead for a more automated way of invoking the ``uic`` tool.


code:
remove
------

.. deprecated:: 3.0

  Use the :command:`list(REMOVE_ITEM)` command instead.

.. code-block:: cmake

  remove(VAR VALUE VALUE ...)

Removes ``VALUE`` from the variable ``VAR``.  This is typically used to
remove entries from a vector (e.g.  semicolon separated list).  ``VALUE``
is expanded.


code:
remove_definitions
------------------

Remove -D define flags added by :command:`add_definitions`.

.. code-block:: cmake

  remove_definitions(-DFOO -DBAR ...)

Removes flags (added by :command:`add_definitions`) from the compiler
command line for sources in the current directory and below.


code:
return
------

Return from a file, directory or function.

.. code-block:: cmake

  return([PROPAGATE <var-name>...])

When this command is encountered in an included file (via :command:`include` or
:command:`find_package`), it causes processing of the current file to stop
and control is returned to the including file.  If it is encountered in a
file which is not included by another file, e.g. a ``CMakeLists.txt``,
deferred calls scheduled by :command:`cmake_language(DEFER)` are invoked and
control is returned to the parent directory if there is one.

If ``return()`` is called in a function, control is returned to the caller
of that function.  Note that a :command:`macro`, unlike a :command:`function`,
is expanded in place and therefore cannot handle ``return()``.

Policy :policy:`CMP0140` controls the behavior regarding the arguments of the
command.  All arguments are ignored unless that policy is set to ``NEW``.

``PROPAGATE``
  .. versionadded:: 3.25

  This option sets or unsets the specified variables in the parent directory or
  function caller scope. This is equivalent to :command:`set(PARENT_SCOPE)` or
  :command:`unset(PARENT_SCOPE)` commands, except for the way it interacts
  with the :command:`block` command, as described below.

  The ``PROPAGATE`` option can be very useful in conjunction with the
  :command:`block` command.  A ``return`` will propagate the
  specified variables through any enclosing block scopes created by the
  :command:`block` commands.  Inside a function, this ensures the variables
  are propagated to the function's caller, regardless of any blocks within
  the function.  If not inside a function, it ensures the variables are
  propagated to the parent file or directory scope. For example:

  .. code-block:: cmake
    :caption: CMakeLists.txt

    cmake_minimum_required(VERSION 3.25)
    project(example)

    set(var1 "top-value")

    block(SCOPE_FOR VARIABLES)
      add_subdirectory(subDir)
      # var1 has the value "block-nested"
    endblock()

    # var1 has the value "top-value"

  .. code-block:: cmake
    :caption: subDir/CMakeLists.txt

    function(multi_scopes result_var1 result_var2)
      block(SCOPE_FOR VARIABLES)
        # This would only propagate out of the immediate block, not to
        # the caller of the function.
        #set(${result_var1} "new-value" PARENT_SCOPE)
        #unset(${result_var2} PARENT_SCOPE)

        # This propagates the variables through the enclosing block and
        # out to the caller of the function.
        set(${result_var1} "new-value")
        unset(${result_var2})
        return(PROPAGATE ${result_var1} ${result_var2})
      endblock()
    endfunction()

    set(var1 "some-value")
    set(var2 "another-value")

    multi_scopes(var1 var2)
    # Now var1 will hold "new-value" and var2 will be unset

    block(SCOPE_FOR VARIABLES)
      # This return() will set var1 in the directory scope that included us
      # via add_subdirectory(). The surrounding block() here does not limit
      # propagation to the current file, but the block() in the parent
      # directory scope does prevent propagation going any further.
      set(var1 "block-nested")
      return(PROPAGATE var1)
    endblock()

See Also
^^^^^^^^

* :command:`block`
* :command:`function`