Help: Use signature directive for 'install' command

Replace manual anchors with signature directives.  Indent each
signature's documentation inside its directive.

Help/command/install.rst

@@ -125,857 +125,885 @@ Installing Targets
 ^^^^^^^^^^^^^^^^^^
 
 .. _`install(TARGETS)`:
-.. _TARGETS:
-
-.. code-block:: cmake
-
-  install(TARGETS targets... [EXPORT <export-name>]
-          [RUNTIME_DEPENDENCIES args...|RUNTIME_DEPENDENCY_SET <set-name>]
-          [[ARCHIVE|LIBRARY|RUNTIME|OBJECTS|FRAMEWORK|BUNDLE|
-            PRIVATE_HEADER|PUBLIC_HEADER|RESOURCE|FILE_SET <set-name>|CXX_MODULES_BMI]
-           [DESTINATION <dir>]
-           [PERMISSIONS permissions...]
-           [CONFIGURATIONS [Debug|Release|...]]
-           [COMPONENT <component>]
-           [NAMELINK_COMPONENT <component>]
-           [OPTIONAL] [EXCLUDE_FROM_ALL]
-           [NAMELINK_ONLY|NAMELINK_SKIP]
-          ] [...]
-          [INCLUDES DESTINATION [<dir> ...]]
-          )
-
-The ``TARGETS`` form specifies rules for installing targets from a
-project.  There are several kinds of target :ref:`Output Artifacts`
-that may be installed:
-
-``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>``
-  .. versionadded:: 3.23
-
-  File sets are defined by the :command:`target_sources(FILE_SET)` command.
-  If the file set ``<set>`` 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``
-
-  .. note ::
-
-    Experimental. Gated by ``CMAKE_EXPERIMENTAL_CXX_MODULE_CMAKE_API``
-
-  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 each of these arguments given, the arguments following them only apply
-to the target or file type specified in the argument. If none is given, the
-installation properties apply to all target types.
-
-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 recommended that they use a
-path that begins with the appropriate :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.
-
-  Consider the following example:
 
-  .. code-block:: cmake
-
-    install(TARGETS mylib
-            LIBRARY
-              COMPONENT Libraries
-              NAMELINK_COMPONENT Development
-            PUBLIC_HEADER
-              COMPONENT Development
-           )
-
-  In this scenario, if you choose to install only the ``Development``
-  component, both the headers and namelink will be installed without the
-  library. (If you don't also install the ``Libraries`` component, the
-  namelink will be a dangling symlink, and projects that link to the library
-  will have build errors.) If you install only the ``Libraries`` component,
-  only the library will be installed, without the headers and namelink.
-
-  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 `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 `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 `install(EXPORT)`_ command. If a
-  relative path is specified, it is treated as relative to the
-  :genex:`$<INSTALL_PREFIX>`.
-
-``RUNTIME_DEPENDENCY_SET``
-  .. versionadded:: 3.21
+.. signature::
+  install(TARGETS <target>... [...])
 
-  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
-  `install(RUNTIME_DEPENDENCY_SET)`_ command.
+  Install target :ref:`Output Artifacts` and associated files:
 
-  This keyword and the ``RUNTIME_DEPENDENCIES`` keyword are mutually
-  exclusive.
+  .. code-block:: cmake
 
-``RUNTIME_DEPENDENCIES``
-  .. versionadded:: 3.21
+    install(TARGETS targets... [EXPORT <export-name>]
+            [RUNTIME_DEPENDENCIES args...|RUNTIME_DEPENDENCY_SET <set-name>]
+            [[ARCHIVE|LIBRARY|RUNTIME|OBJECTS|FRAMEWORK|BUNDLE|
+              PRIVATE_HEADER|PUBLIC_HEADER|RESOURCE|FILE_SET <set-name>|CXX_MODULES_BMI]
+             [DESTINATION <dir>]
+             [PERMISSIONS permissions...]
+             [CONFIGURATIONS [Debug|Release|...]]
+             [COMPONENT <component>]
+             [NAMELINK_COMPONENT <component>]
+             [OPTIONAL] [EXCLUDE_FROM_ALL]
+             [NAMELINK_ONLY|NAMELINK_SKIP]
+            ] [...]
+            [INCLUDES DESTINATION [<dir> ...]]
+            )
+
+  The ``TARGETS`` form specifies rules for installing targets from a
+  project.  There are several kinds of target :ref:`Output Artifacts`
+  that may be installed:
+
+  ``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>``
+    .. versionadded:: 3.23
+
+    File sets are defined by the :command:`target_sources(FILE_SET)` command.
+    If the file set ``<set>`` 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``
+
+    .. note ::
+
+      Experimental. Gated by ``CMAKE_EXPERIMENTAL_CXX_MODULE_CMAKE_API``
+
+    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 each of these arguments given, the arguments following them only apply
+  to the target or file type specified in the argument. If none is given, the
+  installation properties apply to all target types.
+
+  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 recommended that they use a
+  path that begins with the appropriate :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:
 
-  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.
+  .. code-block:: cmake
 
-  ``RUNTIME_DEPENDENCIES`` is semantically equivalent to the following pair
-  of calls:
+    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.
+
+    Consider the following example:
+
+    .. code-block:: cmake
+
+      install(TARGETS mylib
+              LIBRARY
+                COMPONENT Libraries
+                NAMELINK_COMPONENT Development
+              PUBLIC_HEADER
+                COMPONENT Development
+             )
+
+    In this scenario, if you choose to install only the ``Development``
+    component, both the headers and namelink will be installed without the
+    library. (If you don't also install the ``Libraries`` component, the
+    namelink will be a dangling symlink, and projects that link to the library
+    will have build errors.) If you install only the ``Libraries`` component,
+    only the library will be installed, without the headers and namelink.
+
+    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 `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 `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 `install(EXPORT)`_ command. If a
+    relative path is specified, it is treated as relative to the
+    :genex:`$<INSTALL_PREFIX>`.
+
+  ``RUNTIME_DEPENDENCY_SET``
+    .. 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
+    `install(RUNTIME_DEPENDENCY_SET)`_ command.
+
+    This keyword and the ``RUNTIME_DEPENDENCIES`` keyword are mutually
+    exclusive.
+
+  ``RUNTIME_DEPENDENCIES``
+    .. 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> args...)
+
+    where ``<set-name>`` will be a randomly generated set name.
+    The ``args...`` may include any of the following keywords supported by
+    the `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.
+
+  One or more groups of properties may be specified in a single call to
+  the ``TARGETS`` form of this command.  A target may be installed more than
+  once to different locations.  Consider hypothetical targets ``myExe``,
+  ``mySharedLib``, and ``myStaticLib``.  The code:
 
   .. code-block:: cmake
 
-    install(TARGETS ... RUNTIME_DEPENDENCY_SET <set-name>)
-    install(RUNTIME_DEPENDENCY_SET <set-name> args...)
-
-  where ``<set-name>`` will be a randomly generated set name.
-  The ``args...`` may include any of the following keywords supported by
-  the `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.
-
-One or more groups of properties may be specified in a single call to
-the ``TARGETS`` form of this command.  A target may be installed more than
-once to different locations.  Consider hypothetical targets ``myExe``,
-``mySharedLib``, and ``myStaticLib``.  The code:
-
-.. code-block:: cmake
-
-  install(TARGETS myExe mySharedLib myStaticLib
-          RUNTIME DESTINATION bin
-          LIBRARY DESTINATION lib
-          ARCHIVE DESTINATION lib/static)
-  install(TARGETS mySharedLib DESTINATION /some/full/path)
-
-will install ``myExe`` to ``<prefix>/bin`` and ``myStaticLib`` to
-``<prefix>/lib/static``.  On non-DLL platforms ``mySharedLib`` will be
-installed to ``<prefix>/lib`` and ``/some/full/path``.  On DLL platforms
-the ``mySharedLib`` DLL will be installed to ``<prefix>/bin`` and
-``/some/full/path`` and its import library will be installed to
-``<prefix>/lib/static`` and ``/some/full/path``.
-
-: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
-  `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.
+    install(TARGETS myExe mySharedLib myStaticLib
+            RUNTIME DESTINATION bin
+            LIBRARY DESTINATION lib
+            ARCHIVE DESTINATION lib/static)
+    install(TARGETS mySharedLib DESTINATION /some/full/path)
+
+  will install ``myExe`` to ``<prefix>/bin`` and ``myStaticLib`` to
+  ``<prefix>/lib/static``.  On non-DLL platforms ``mySharedLib`` will be
+  installed to ``<prefix>/lib`` and ``/some/full/path``.  On DLL platforms
+  the ``mySharedLib`` DLL will be installed to ``<prefix>/bin`` and
+  ``/some/full/path`` and its import library will be installed to
+  ``<prefix>/lib/static`` and ``/some/full/path``.
+
+  :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
+    `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.
 
 Installing Imported Runtime Artifacts
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 .. _`install(IMPORTED_RUNTIME_ARTIFACTS)`:
-.. _IMPORTED_RUNTIME_ARTIFACTS:
-
-.. versionadded:: 3.21
-
-.. code-block:: cmake
-
-  install(IMPORTED_RUNTIME_ARTIFACTS targets...
-          [RUNTIME_DEPENDENCY_SET <set-name>]
-          [[LIBRARY|RUNTIME|FRAMEWORK|BUNDLE]
-           [DESTINATION <dir>]
-           [PERMISSIONS permissions...]
-           [CONFIGURATIONS [Debug|Release|...]]
-           [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 `install(RUNTIME_DEPENDENCY_SET)`_ command.
+
+.. signature::
+  install(IMPORTED_RUNTIME_ARTIFACTS <target>... [...])
+
+  .. versionadded:: 3.21
+
+  Install runtime artifacts of imported targets:
+
+  .. code-block:: cmake
+
+    install(IMPORTED_RUNTIME_ARTIFACTS targets...
+            [RUNTIME_DEPENDENCY_SET <set-name>]
+            [[LIBRARY|RUNTIME|FRAMEWORK|BUNDLE]
+             [DESTINATION <dir>]
+             [PERMISSIONS permissions...]
+             [CONFIGURATIONS [Debug|Release|...]]
+             [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 `install(RUNTIME_DEPENDENCY_SET)`_ command.
 
 Installing Files
 ^^^^^^^^^^^^^^^^
 
 .. _`install(FILES)`:
 .. _`install(PROGRAMS)`:
-.. _FILES:
-.. _PROGRAMS:
 
-.. note::
+.. signature::
+  install(FILES <file>... [...])
+  install(PROGRAMS <program>... [...])
 
-  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.
-
-.. code-block:: cmake
-
-  install(<FILES|PROGRAMS> files...
-          TYPE <type> | DESTINATION <dir>
-          [PERMISSIONS permissions...]
-          [CONFIGURATIONS [Debug|Release|...]]
-          [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 recommended that they use a
-path that begins with the appropriate :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.
+  .. 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
 
-.. versionadded:: 3.20
-  An install rename given as a ``RENAME`` argument may
-  use "generator expressions" with the syntax ``$<...>``.  See the
+    install(<FILES|PROGRAMS> files...
+            TYPE <type> | DESTINATION <dir>
+            [PERMISSIONS permissions...]
+            [CONFIGURATIONS [Debug|Release|...]]
+            [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 recommended that they use a
+  path that begins with the appropriate :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.
 
 Installing Directories
 ^^^^^^^^^^^^^^^^^^^^^^
 
 .. _`install(DIRECTORY)`:
-.. _DIRECTORY:
 
-.. note::
+.. signature::
+  install(DIRECTORY <dir>... [...])
 
-  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.
-
-.. code-block:: cmake
-
-  install(DIRECTORY dirs...
-          TYPE <type> | DESTINATION <dir>
-          [FILE_PERMISSIONS permissions...]
-          [DIRECTORY_PERMISSIONS permissions...]
-          [USE_SOURCE_PERMISSIONS] [OPTIONAL] [MESSAGE_NEVER]
-          [CONFIGURATIONS [Debug|Release|...]]
-          [COMPONENT <component>] [EXCLUDE_FROM_ALL]
-          [FILES_MATCHING]
-          [[PATTERN <pattern> | REGEX <regex>]
-           [EXCLUDE] [PERMISSIONS permissions...]] [...])
-
-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.
+  .. note::
 
-.. 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 recommended that they use a
-path that begins with the appropriate :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.
+    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.
 
-.. versionadded:: 3.5
-  The list of ``dirs...`` given to ``DIRECTORY`` may use
-  "generator expressions" too.
+  Install the contents of one or more directories:
+
+  .. code-block:: cmake
+
+    install(DIRECTORY dirs...
+            TYPE <type> | DESTINATION <dir>
+            [FILE_PERMISSIONS permissions...]
+            [DIRECTORY_PERMISSIONS permissions...]
+            [USE_SOURCE_PERMISSIONS] [OPTIONAL] [MESSAGE_NEVER]
+            [CONFIGURATIONS [Debug|Release|...]]
+            [COMPONENT <component>] [EXCLUDE_FROM_ALL]
+            [FILES_MATCHING]
+            [[PATTERN <pattern> | REGEX <regex>]
+             [EXCLUDE] [PERMISSIONS permissions...]] [...])
+
+  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 recommended that they use a
+  path that begins with the appropriate :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.
 
 Custom Installation Logic
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 .. _`install(CODE)`:
 .. _`install(SCRIPT)`:
-.. _CODE:
-.. _SCRIPT:
 
-.. code-block:: cmake
+.. signature::
+  install(SCRIPT <file> [...])
+  install(CODE <code> [...])
+
+  Invoke CMake scripts or code during installation:
 
-  install([[SCRIPT <file>] [CODE <code>]]
-          [ALL_COMPONENTS | COMPONENT <component>]
-          [EXCLUDE_FROM_ALL] [...])
+  .. code-block:: cmake
 
-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
+    install([[SCRIPT <file>] [CODE <code>]]
+            [ALL_COMPONENTS | COMPONENT <component>]
+            [EXCLUDE_FROM_ALL] [...])
 
-.. code-block:: cmake
+  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
 
-  install(CODE "MESSAGE(\"Sample install message.\")")
+  .. code-block:: cmake
 
-will print a message during installation.
+    install(CODE "MESSAGE(\"Sample install message.\")")
 
-.. 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.
+  will print a message during installation.
 
-.. 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.
+  .. 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.
 
 Installing Exports
 ^^^^^^^^^^^^^^^^^^
 
 .. _`install(EXPORT)`:
-.. _EXPORT:
-
-.. code-block:: cmake
-
-  install(EXPORT <export-name> DESTINATION <dir>
-          [NAMESPACE <namespace>] [FILE <name>.cmake]
-          [PERMISSIONS permissions...]
-          [CONFIGURATIONS [Debug|Release|...]
-          [CXX_MODULES_DIRECTORY <directory>]
-          [EXPORT_LINK_INTERFACE_LIBRARIES]
-          [COMPONENT <component>]
-          [EXCLUDE_FROM_ALL])
-  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 `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``
-
-  .. note ::
-
-    Experimental. Gated by ``CMAKE_EXPERIMENTAL_CXX_MODULE_CMAKE_API``
-
-  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.
-
-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.
+.. signature::
+  install(EXPORT <export-name> [...])
 
-.. 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.
+  Install a CMake file exporting targets for dependent projects:
+
+  .. code-block:: cmake
+
+    install(EXPORT <export-name> DESTINATION <dir>
+            [NAMESPACE <namespace>] [FILE <name>.cmake]
+            [PERMISSIONS permissions...]
+            [CONFIGURATIONS [Debug|Release|...]
+            [CXX_MODULES_DIRECTORY <directory>]
+            [EXPORT_LINK_INTERFACE_LIBRARIES]
+            [COMPONENT <component>]
+            [EXCLUDE_FROM_ALL])
+    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 `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``
+
+    .. note ::
+
+      Experimental. Gated by ``CMAKE_EXPERIMENTAL_CXX_MODULE_CMAKE_API``
+
+    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.
+
+  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.
 
 Installing Runtime Dependencies
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 .. _`install(RUNTIME_DEPENDENCY_SET)`:
-.. _RUNTIME_DEPENDENCY_SET:
-
-.. versionadded:: 3.21
-
-.. code-block:: cmake
-
-  install(RUNTIME_DEPENDENCY_SET <set-name>
-          [[LIBRARY|RUNTIME|FRAMEWORK]
-           [DESTINATION <dir>]
-           [PERMISSIONS permissions...]
-           [CONFIGURATIONS [Debug|Release|...]]
-           [COMPONENT <component>]
-           [NAMELINK_COMPONENT <component>]
-           [OPTIONAL] [EXCLUDE_FROM_ALL]
-          ] [...]
-          [PRE_INCLUDE_REGEXES regexes...]
-          [PRE_EXCLUDE_REGEXES regexes...]
-          [POST_INCLUDE_REGEXES regexes...]
-          [POST_EXCLUDE_REGEXES regexes...]
-          [POST_INCLUDE_FILES files...]
-          [POST_EXCLUDE_FILES files...]
-          [DIRECTORIES directories...]
-          )
-
-Installs a runtime dependency set previously created by one or more
-`install(TARGETS)`_ or `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 `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 <directories>``
-* ``PRE_INCLUDE_REGEXES <regexes>``
-* ``PRE_EXCLUDE_REGEXES <regexes>``
-* ``POST_INCLUDE_REGEXES <regexes>``
-* ``POST_EXCLUDE_REGEXES <regexes>``
-* ``POST_INCLUDE_FILES <files>``
-* ``POST_EXCLUDE_FILES <files>``
+
+.. 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 permissions...]
+             [CONFIGURATIONS [Debug|Release|...]]
+             [COMPONENT <component>]
+             [NAMELINK_COMPONENT <component>]
+             [OPTIONAL] [EXCLUDE_FROM_ALL]
+            ] [...]
+            [PRE_INCLUDE_REGEXES regexes...]
+            [PRE_EXCLUDE_REGEXES regexes...]
+            [POST_INCLUDE_REGEXES regexes...]
+            [POST_EXCLUDE_REGEXES regexes...]
+            [POST_INCLUDE_FILES files...]
+            [POST_EXCLUDE_FILES files...]
+            [DIRECTORIES directories...]
+            )
+
+  Installs a runtime dependency set previously created by one or more
+  `install(TARGETS)`_ or `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 `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 <directories>``
+  * ``PRE_INCLUDE_REGEXES <regexes>``
+  * ``PRE_EXCLUDE_REGEXES <regexes>``
+  * ``POST_INCLUDE_REGEXES <regexes>``
+  * ``POST_EXCLUDE_REGEXES <regexes>``
+  * ``POST_INCLUDE_FILES <files>``
+  * ``POST_EXCLUDE_FILES <files>``
 
 Generated Installation Script
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^