Help: Use *.rst extension for included files

So, editor(s) can correctly highlight the RST syntax in the included files.

Help/variable/include/CMAKE_FIND_ROOT_PATH_MODE_XXX.rst

@@ -0,0 +1,8 @@
+This variable controls whether the :variable:`CMAKE_FIND_ROOT_PATH` and
+:variable:`CMAKE_SYSROOT` are used by |FIND_XXX|.
+
+If set to ``ONLY``, then only the roots in :variable:`CMAKE_FIND_ROOT_PATH`
+will be searched. If set to ``NEVER``, then the roots in
+:variable:`CMAKE_FIND_ROOT_PATH` will be ignored and only the host system
+root will be used. If set to ``BOTH``, then the host system paths and the
+paths in :variable:`CMAKE_FIND_ROOT_PATH` will be searched.

Help/variable/include/CMAKE_LINK_GROUP_USING_FEATURE.rst

@@ -0,0 +1,78 @@
+Feature names are case-sensitive and may only contain letters, numbers
+and underscores.  Feature names defined in all uppercase are reserved for
+CMake's own built-in features (see `Predefined Features`_ further below).
+
+
+Feature Definitions
+^^^^^^^^^^^^^^^^^^^
+
+A group feature definition is a list that contains exactly two elements:
+
+::
+
+  <PREFIX> <SUFFIX>
+
+On the linker command line, ``<PREFIX>`` will precede the list of libraries
+in the group and ``<SUFFIX>`` will follow after.
+
+For the elements of this variable, the ``LINKER:`` prefix can be used.
+
+.. include:: ../command/include/LINK_OPTIONS_LINKER.rst
+  :start-line: 3
+
+Examples
+^^^^^^^^
+
+Solving cross-references between two static libraries
+"""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+A project may define two or more static libraries which have circular
+dependencies between them.  In order for the linker to resolve all symbols
+at link time, it may need to search repeatedly among the libraries until no
+new undefined references are created.  Different linkers use different syntax
+for achieving this.  The following example shows how this may be implemented
+for some linkers.  Note that this is for illustration purposes only.
+Projects should use the built-in ``RESCAN`` group feature instead
+(see `Predefined Features`_), which provides a more complete and more robust
+implementation of this functionality.
+
+.. code-block:: cmake
+
+  set(CMAKE_C_LINK_GROUP_USING_cross_refs_SUPPORTED TRUE)
+  if(CMAKE_C_COMPILER_ID STREQUAL "GNU" AND CMAKE_SYSTEM_NAME STREQUAL "Linux")
+    set(CMAKE_C_LINK_GROUP_USING_cross_refs
+      "LINKER:--start-group"
+      "LINKER:--end-group"
+    )
+  elseif(CMAKE_C_COMPILER_ID STREQUAL "SunPro" AND CMAKE_SYSTEM_NAME STREQUAL "SunOS")
+    set(CMAKE_C_LINK_GROUP_USING_cross_refs
+      "LINKER:-z,rescan-start"
+      "LINKER:-z,rescan-end"
+    )
+  else()
+    # feature not yet supported for the other environments
+    set(CMAKE_C_LINK_GROUP_USING_cross_refs_SUPPORTED FALSE)
+  endif()
+
+  add_library(lib1 STATIC ...)
+  add_library(lib2 SHARED ...)
+
+  if(CMAKE_C_LINK_GROUP_USING_cross_refs_SUPPORTED)
+    target_link_libraries(lib2 PRIVATE "$<LINK_GROUP:cross_refs,lib1,external>")
+  else()
+    target_link_libraries(lib2 PRIVATE lib1 external)
+  endif()
+
+CMake will generate the following linker command line fragments when linking
+``lib2``:
+
+* ``GNU``: ``-Wl,--start-group /path/to/lib1.a -lexternal -Wl,--end-group``
+* ``SunPro``: ``-Wl,-z,rescan-start /path/to/lib1.a -lexternal -Wl,-z,rescan-end``
+
+
+Predefined Features
+^^^^^^^^^^^^^^^^^^^
+
+The following built-in group features are pre-defined by CMake:
+
+.. include:: include/LINK_GROUP_PREDEFINED_FEATURES.rst

Help/variable/include/CMAKE_LINK_LIBRARY_USING_FEATURE.rst

@@ -0,0 +1,153 @@
+Feature names are case-sensitive and may only contain letters, numbers
+and underscores.  Feature names defined in all uppercase are reserved for
+CMake's own built-in features (see `Predefined Features`_ further below).
+
+Some aspects of feature behavior can be defined by the
+:variable:`CMAKE_<LANG>_LINK_LIBRARY_<FEATURE>_ATTRIBUTES` and
+:variable:`CMAKE_LINK_LIBRARY_<FEATURE>_ATTRIBUTES` variables.
+
+Feature Definitions
+^^^^^^^^^^^^^^^^^^^
+
+A library feature definition is a list that contains one or three elements:
+
+::
+
+  [<PREFIX>] <LIBRARY_EXPRESSION> [<SUFFIX>]
+
+When ``<PREFIX>`` and ``<SUFFIX>`` are specified, they precede and follow
+respectively the whole list of libraries specified in the
+:genex:`LINK_LIBRARY` expression, not each library item individually.
+There is no guarantee that the list of specified libraries will be kept
+grouped together though, so the ``<PREFIX>`` and ``<SUFFIX>`` may appear
+more than once if the library list is reorganized by CMake to satisfy other
+constraints.  This means constructs like ``--start-group`` and ``--end-group``,
+as supported by the GNU ``ld`` linker, cannot be used in this way.  The
+:genex:`LINK_GROUP` generator expression should be used instead for such
+constructs.
+
+``<LIBRARY_EXPRESSION>`` is used to specify the pattern for constructing the
+corresponding fragment on the linker command line for each library.
+The following placeholders can be used in the expression:
+
+* ``<LIBRARY>`` is expanded to the full path to the library for CMake targets,
+  or to a platform-specific value based on the item otherwise (the same as
+  ``<LINK_ITEM>`` on Windows, or the library base name for other platforms).
+* ``<LINK_ITEM>`` is expanded to how the library would normally be linked on
+  the linker command line.
+* ``<LIB_ITEM>`` is expanded to the full path to the library for CMake targets,
+  or the item itself exactly as specified in the ``<LIBRARY_EXPRESSION>``
+  otherwise.
+
+In addition to the above, it is possible to have one pattern for paths
+(CMake targets and external libraries specified with file paths) and another
+for other items specified by name only.  The ``PATH{}`` and ``NAME{}`` wrappers
+can be used to provide the expansion for those two cases, respectively.
+When wrappers are used, both must be present.  For example:
+
+.. code-block:: cmake
+
+  set(CMAKE_LINK_LIBRARY_USING_weak_library
+      "PATH{-weak_library <LIBRARY>}NAME{LINKER:-weak-l<LIB_ITEM>}"
+  )
+
+For all three elements of this variable (``<PREFIX>``, ``<LIBRARY_EXPRESSION>``,
+and ``<SUFFIX>``), the ``LINKER:`` prefix can be used.
+
+.. include:: ../command/include/LINK_OPTIONS_LINKER.rst
+  :start-line: 3
+
+Examples
+^^^^^^^^
+
+Loading a whole static library
+""""""""""""""""""""""""""""""
+
+A common need is to prevent the linker from discarding any symbols from a
+static library.  Different linkers use different syntax for achieving this.
+The following example shows how this may be implemented for some linkers.
+Note that this is for illustration purposes only.  Projects should use the
+built-in ``WHOLE_ARCHIVE`` feature instead (see `Predefined Features`_), which
+provides a more complete and more robust implementation of this functionality.
+
+.. code-block:: cmake
+
+  set(CMAKE_C_LINK_LIBRARY_USING_load_archive_SUPPORTED TRUE)
+  if(CMAKE_C_COMPILER_ID STREQUAL "AppleClang")
+    set(CMAKE_C_LINK_LIBRARY_USING_load_archive "-force_load <LIB_ITEM>")
+  elseif(CMAKE_C_COMPILER_ID STREQUAL "GNU" AND CMAKE_SYSTEM_NAME STREQUAL "Linux")
+    set(CMAKE_C_LINK_LIBRARY_USING_load_archive
+      "LINKER:--push-state,--whole-archive"
+      "<LINK_ITEM>"
+      "LINKER:--pop-state"
+    )
+  elseif(CMAKE_C_COMPILER_ID STREQUAL "MSVC")
+    set(CMAKE_C_LINK_LIBRARY_USING_load_archive "/WHOLEARCHIVE:<LIBRARY>")
+  else()
+    # feature not yet supported for the other environments
+    set(CMAKE_C_LINK_LIBRARY_USING_load_archive_SUPPORTED FALSE)
+  endif()
+
+  add_library(lib1 STATIC ...)
+  add_library(lib2 SHARED ...)
+
+  if(CMAKE_C_LINK_LIBRARY_USING_load_archive_SUPPORTED)
+    # The -force_load Apple linker option requires a file name
+    set(external_lib
+      "$<IF:$<LINK_LANG_AND_ID:C,AppleClang>,libexternal.a,external>"
+    )
+    target_link_libraries(lib2 PRIVATE
+      "$<LINK_LIBRARY:load_archive,lib1,${external_lib}>"
+    )
+  else()
+    target_link_libraries(lib2 PRIVATE lib1 external)
+  endif()
+
+CMake will generate the following link expressions:
+
+* ``AppleClang``: ``-force_load /path/to/lib1.a -force_load libexternal.a``
+* ``GNU``: ``-Wl,--push-state,--whole-archive /path/to/lib1.a -lexternal -Wl,--pop-state``
+* ``MSVC``: ``/WHOLEARCHIVE:/path/to/lib1.lib /WHOLEARCHIVE:external.lib``
+
+Linking a library as weak
+"""""""""""""""""""""""""
+
+On macOS, it is possible to link a library in weak mode (the library and all
+references are marked as weak imports).  Different flags must be used for a
+library specified by file path compared to one specified by name.
+This constraint can be solved using ``PATH{}`` and ``NAME{}`` wrappers.
+Again, the following example shows how this may be implemented for some
+linkers, but it is for illustration purposes only.  Projects should use the
+built-in ``WEAK_FRAMEWORK`` or ``WEAK_LIBRARY`` features instead (see
+`Predefined Features`_), which provide more complete and more robust
+implementations of this functionality.
+
+.. code-block:: cmake
+
+  if (CMAKE_C_COMPILER_ID STREQUAL "AppleClang")
+    set(CMAKE_LINK_LIBRARY_USING_weak_library
+        "PATH{-weak_library <LIBRARY>}NAME{LINKER:-weak-l<LIB_ITEM>}"
+    )
+    set(CMAKE_LINK_LIBRARY_USING_weak_library_SUPPORTED TRUE)
+  endif()
+
+  add_library(lib SHARED ...)
+  add_executable(main ...)
+  if(CMAKE_LINK_LIBRARY_USING_weak_library_SUPPORTED)
+    target_link_libraries(main PRIVATE "$<LINK_LIBRARY:weak_library,lib,external>")
+  else()
+    target_link_libraries(main PRIVATE lib external)
+  endif()
+
+CMake will generate the following linker command line fragment when linking
+``main`` using the ``AppleClang`` toolchain:
+
+``-weak_library /path/to/lib -Xlinker -weak-lexternal``.
+
+
+Predefined Features
+^^^^^^^^^^^^^^^^^^^
+
+The following built-in library features are pre-defined by CMake:
+
+.. include:: include/LINK_LIBRARY_PREDEFINED_FEATURES.rst

Help/variable/include/CMAKE_OSX_VARIABLE.rst

@@ -0,0 +1,12 @@
+The value of this variable should be set prior to the first
+:command:`project` or :command:`enable_language` command invocation
+because it may influence configuration of the toolchain and flags.
+It is intended to be set locally by the user creating a build tree.
+This variable should be set as a ``CACHE`` entry (or else CMake may
+remove it while initializing a cache entry of the same name) unless
+policy :policy:`CMP0126` is set to ``NEW``.
+
+Despite the ``OSX`` part in the variable name(s) they apply also to
+other SDKs than macOS like iOS, tvOS, visionOS, or watchOS.
+
+This variable is ignored on platforms other than Apple.

Help/variable/include/CMAKE_TLS_VERSION-VALUES.rst

@@ -0,0 +1,7 @@
+* ``1.0``
+
+* ``1.1``
+
+* ``1.2``
+
+* ``1.3``

Help/variable/include/CMAKE_VS_VERSION_BUILD_NUMBER_COMPONENTS.rst

@@ -0,0 +1,18 @@
+The components are:
+
+``<major>.<minor>``
+
+  The VS major and minor version numbers.
+  These are the same as the release version numbers.
+
+``<date>``
+
+  A build date in the format ``MMMDD``, where ``MMM`` is a month index
+  since an epoch used by Microsoft, and ``DD`` is a day in that month.
+
+``<build>``
+
+  A build index on the day represented by ``<date>``.
+
+The build number is reported by ``vswhere`` as ``installationVersion``.
+For example, VS 16.11.10 has build number ``16.11.32126.315``.

Help/variable/include/CTEST_CUSTOM_XXX.rst

@@ -0,0 +1,2 @@
+It is initialized by :manual:`ctest(1)`, but may be edited in a ``CTestCustom``
+file. See :command:`ctest_read_custom_files` documentation.

Help/variable/include/IGNORE_SEARCH_LOCATIONS.rst

@@ -0,0 +1,4 @@
+Ignoring search locations can be useful in cross-compiling environments where
+some system directories contain incompatible but possibly linkable libraries.
+For example, on cross-compiled cluster environments, this allows a user to
+ignore directories containing libraries meant for the front-end machine.

Help/variable/include/IGNORE_SEARCH_NONSYSTEM.rst

@@ -0,0 +1,2 @@
+By default, |CMAKE_IGNORE_VAR| is empty. It is intended to be set by the
+project or the end user.

Help/variable/include/IGNORE_SEARCH_PATH.rst

@@ -0,0 +1,19 @@
+:ref:`Semicolon-separated list <CMake Language Lists>` of directories
+to be ignored by the various ``find...()`` commands.
+
+For :command:`find_program`, :command:`find_library`, :command:`find_file`,
+and :command:`find_path`, any file found in one of the listed directories
+will be ignored. The listed directories do not apply recursively, so any
+subdirectories to be ignored must also be explicitly listed.
+|CMAKE_IGNORE_VAR| does not affect the search *prefixes* used by these
+four commands. To ignore individual paths under a search prefix
+(e.g. ``bin``, ``include``, ``lib``, etc.), each path must be listed in
+|CMAKE_IGNORE_VAR| as a full absolute path. |CMAKE_IGNORE_PREFIX_VAR|
+provides a more appropriate way to ignore a whole search prefix.
+
+:command:`find_package` is also affected by |CMAKE_IGNORE_VAR|, but only
+for *Config mode* searches. Any ``<Name>Config.cmake`` or
+``<name>-config.cmake`` file found in one of the specified directories
+will be ignored. In addition, any search *prefix* found in |CMAKE_IGNORE_VAR|
+will be skipped for backward compatibility reasons, but new code should
+prefer to use |CMAKE_IGNORE_PREFIX_VAR| to ignore prefixes instead.

Help/variable/include/IGNORE_SEARCH_PREFIX.rst

@@ -0,0 +1,6 @@
+:ref:`Semicolon-separated list <CMake Language Lists>` of search *prefixes*
+to be ignored by the :command:`find_program`, :command:`find_library`,
+:command:`find_file`, and :command:`find_path` commands.
+The prefixes are also ignored by the *Config mode* of the
+:command:`find_package` command (*Module mode* is unaffected).
+To ignore specific directories instead, see |CMAKE_IGNORE_NONPREFIX_VAR|.

Help/variable/include/IGNORE_SEARCH_SYSTEM.rst

@@ -0,0 +1,5 @@
+|CMAKE_IGNORE_VAR| is populated by CMake as part of its platform
+and toolchain setup. Its purpose is to ignore locations containing
+incompatible binaries meant for the host rather than the target platform.
+The project or end user should not modify this variable, they should use
+|CMAKE_IGNORE_NONSYSTEM_VAR| instead.

Help/variable/include/LINKER_FLAGS.rst

@@ -0,0 +1,5 @@
+
+.. include:: ../command/include/LINK_LIBRARIES_LINKER.rst
+
+This support implies to parse and re-quote the content of the variable. See
+policy :policy:`CMP0181`.

Help/variable/include/LINKER_PREDEFINED_TYPES.rst

@@ -0,0 +1,69 @@
+.. note::
+  It is assumed that the linker specified is fully compatible with the default
+  one the compiler would normally invoke. CMake will not do any option
+  translation.
+
+Linker types are case-sensitive and may only contain letters, numbers and
+underscores. Linker types defined in all uppercase are reserved for CMake's own
+built-in types. The pre-defined linker types are:
+
+``DEFAULT``
+  This type corresponds to standard linking, essentially equivalent to the
+  :prop_tgt:`LINKER_TYPE` target property not being set at all.
+
+``SYSTEM``
+  Use the standard linker provided by the platform or toolchain. For example,
+  this implies the Microsoft linker for all MSVC-compatible compilers.
+  This type is supported for the following platform-compiler combinations:
+
+  * Linux: ``GNU``, ``Clang``, ``LLVMFlang``, ``NVIDIA``, and ``Swift``
+    compilers.
+  * Apple platforms: ``AppleClang``, ``Clang``, ``GNU``, and ``Swift``
+    compilers.
+  * Windows: ``MSVC``, ``GNU``, ``Clang``, ``NVIDIA``, and ``Swift`` compilers.
+
+``LLD``
+  Use the ``LLVM`` linker. This type is supported for the following
+  platform-compiler combinations:
+
+  * Linux: ``GNU``, ``Clang``, ``LLVMFlang``, ``NVIDIA``, and ``Swift``
+    compilers.
+  * Apple platforms: ``Clang``, ``AppleClang``, and ``Swift`` compilers.
+  * Windows: ``GNU``, ``Clang`` with MSVC-like front-end, ``Clang`` with
+    GNU-like front-end, ``MSVC``, ``NVIDIA`` with MSVC-like front-end,
+    and ``Swift``.
+
+``BFD``
+  Use the ``GNU`` linker.  This type is supported for the following
+  platform-compiler combinations:
+
+  * Linux: ``GNU``, ``Clang``, ``LLVMFlang``, and ``NVIDIA`` compilers.
+  * Windows: ``GNU``, ``Clang`` with GNU-like front-end.
+
+``GOLD``
+  Supported on Linux platform with ``GNU``, ``Clang``, ``LLVMFlang``,
+  ``NVIDIA``, and ``Swift`` compilers.
+
+``MOLD``
+  Use the `mold linker <https://github.com/rui314/mold>`_. This type is
+  supported on the following platform-compiler combinations:
+
+  * Linux: ``GNU``, ``Clang``, ``LLVMFlang``, and ``NVIDIA`` compilers.
+  * Apple platforms: ``Clang`` and ``AppleClang`` compilers (acts as an
+    alias to the `sold linker`_).
+
+``SOLD``
+  Use the `sold linker`_. This type is only supported on Apple platforms
+  with ``Clang`` and ``AppleClang`` compilers.
+
+``APPLE_CLASSIC``
+  Use the Apple linker in the classic behavior (i.e. before ``Xcode 15.0``).
+  This type is only supported on Apple platforms with ``GNU``, ``Clang``,
+  ``AppleClang``, and ``Swift`` compilers.
+
+``MSVC``
+  Use the Microsoft linker. This type is only supported on the Windows
+  platform with ``MSVC``, ``Clang`` with MSVC-like front-end, and ``Swift``
+  compilers.
+
+.. _sold linker: https://github.com/bluewhalesystems/sold

Help/variable/include/LINK_GROUP_PREDEFINED_FEATURES.rst

@@ -0,0 +1,22 @@
+``RESCAN``
+  Some linkers are single-pass only.  For such linkers, circular references
+  between libraries typically result in unresolved symbols.  This feature
+  instructs the linker to search the specified static libraries repeatedly
+  until no new undefined references are created.
+
+  Normally, a static library is searched only once in the order that it is
+  specified on the command line.  If a symbol in that library is needed to
+  resolve an undefined symbol referred to by an object in a library that
+  appears later on the command line, the linker would not be able to resolve
+  that reference.  By grouping the static libraries with the ``RESCAN``
+  feature, they will all be searched repeatedly until all possible references
+  are resolved.  This will use linker options like ``--start-group`` and
+  ``--end-group``, or on SunOS, ``-z rescan-start`` and ``-z rescan-end``.
+
+  Using this feature has a significant performance cost. It is best to use it
+  only when there are unavoidable circular references between two or more
+  static libraries.
+
+  This feature is available when using toolchains that target Linux, BSD, and
+  SunOS.  It can also be used when targeting Windows platforms if the GNU
+  toolchain is used.

Help/variable/include/LINK_LIBRARY_PREDEFINED_FEATURES.rst

@@ -0,0 +1,111 @@
+``DEFAULT``
+  This feature corresponds to standard linking, essentially equivalent to
+  using no feature at all.  It is typically only used with the
+  :prop_tgt:`LINK_LIBRARY_OVERRIDE` and
+  :prop_tgt:`LINK_LIBRARY_OVERRIDE_<LIBRARY>` target properties.
+
+``WHOLE_ARCHIVE``
+  Force inclusion of all members of a static library when linked as a
+  dependency of consuming :ref:`Executables`, :ref:`Shared Libraries`,
+  and :ref:`Module Libraries`.  This feature is only supported for the
+  following platforms, with limitations as noted:
+
+  * Linux.
+  * All BSD variants.
+  * SunOS.
+  * All Apple variants.  The library must be specified as a CMake target name,
+    a library file name (such as ``libfoo.a``), or a library file path (such as
+    ``/path/to/libfoo.a``).  Due to a limitation of the Apple linker, it
+    cannot be specified as a plain library name like ``foo``, where ``foo``
+    is not a CMake target.
+  * Windows.  When using a MSVC or MSVC-like toolchain, the MSVC version must
+    be greater than 1900.
+  * Cygwin.
+  * MSYS.
+
+  .. note::
+
+    Since :ref:`Static Libraries` are archives and not linked binaries,
+    CMake records their link dependencies for transitive use when linking
+    consuming binaries.  Therefore ``WHOLE_ARCHIVE`` does not cause a
+    static library's objects to be included in other static libraries.
+    Use :ref:`Object Libraries` for that.
+
+``FRAMEWORK``
+  This option tells the linker to search for the specified framework using
+  the ``-framework`` linker option.  It can only be used on Apple platforms,
+  and only with a linker that understands the option used (i.e. the linker
+  provided with Xcode, or one compatible with it).
+
+  The framework can be specified as a CMake framework target, a bare framework
+  name, or a file path.  If a target is given, that target must have the
+  :prop_tgt:`FRAMEWORK` target property set to true.  For a file path, if it
+  contains a directory part, that directory will be added as a framework
+  search path.
+
+  .. code-block:: cmake
+
+    add_library(lib SHARED ...)
+    target_link_libraries(lib PRIVATE "$<LINK_LIBRARY:FRAMEWORK,/path/to/my_framework>")
+
+    # The constructed linker command line will contain:
+    #   -F/path/to -framework my_framework
+
+  File paths must conform to one of the following patterns (``*`` is a
+  wildcard, and optional parts are shown as ``[...]``):
+
+  * ``[/path/to/]FwName[.framework]``
+  * ``[/path/to/]FwName.framework/FwName[suffix]``
+  * ``[/path/to/]FwName.framework/Versions/*/FwName[suffix]``
+
+  Note that CMake recognizes and automatically handles framework targets,
+  even without using the :genex:`$<LINK_LIBRARY:FRAMEWORK,...>` expression.
+  The generator expression can still be used with a CMake target if the
+  project wants to be explicit about it, but it is not required to do so.
+  The linker command line may have some differences between using the
+  generator expression or not, but the final result should be the same.
+  On the other hand, if a file path is given, CMake will recognize some paths
+  automatically, but not all cases.  The project may want to use
+  :genex:`$<LINK_LIBRARY:FRAMEWORK,...>` for file paths so that the expected
+  behavior is clear.
+
+  .. versionadded:: 3.25
+    The :prop_tgt:`FRAMEWORK_MULTI_CONFIG_POSTFIX_<CONFIG>` target property as
+    well as the ``suffix`` of the framework library name are now supported by
+    the ``FRAMEWORK`` features.
+
+``NEEDED_FRAMEWORK``
+  This is similar to the ``FRAMEWORK`` feature, except it forces the linker
+  to link with the framework even if no symbols are used from it.  It uses
+  the ``-needed_framework`` option and has the same linker constraints as
+  ``FRAMEWORK``.
+
+``REEXPORT_FRAMEWORK``
+  This is similar to the ``FRAMEWORK`` feature, except it tells the linker
+  that the framework should be available to clients linking to the library
+  being created.  It uses the ``-reexport_framework`` option and has the
+  same linker constraints as ``FRAMEWORK``.
+
+``WEAK_FRAMEWORK``
+  This is similar to the ``FRAMEWORK`` feature, except it forces the linker
+  to mark the framework and all references to it as weak imports.  It uses
+  the ``-weak_framework`` option and has the same linker constraints as
+  ``FRAMEWORK``.
+
+``NEEDED_LIBRARY``
+  This is similar to the ``NEEDED_FRAMEWORK`` feature, except it is for use
+  with non-framework targets or libraries (Apple platforms only).
+  It uses the ``-needed_library`` or ``-needed-l`` option as appropriate,
+  and has the same linker constraints as ``NEEDED_FRAMEWORK``.
+
+``REEXPORT_LIBRARY``
+  This is similar to the ``REEXPORT_FRAMEWORK`` feature,  except it is for use
+  with non-framework targets or libraries (Apple platforms only).
+  It uses the ``-reexport_library`` or ``-reexport-l`` option as appropriate,
+  and has the same linker constraints as ``REEXPORT_FRAMEWORK``.
+
+``WEAK_LIBRARY``
+  This is similar to the ``WEAK_FRAMEWORK`` feature, except it is for use
+  with non-framework targets or libraries (Apple platforms only).
+  It uses the ``-weak_library`` or ``-weak-l`` option as appropriate,
+  and has the same linker constraints as ``WEAK_FRAMEWORK``.