LINK_LIBRARIES_STRATEGY
-----------------------

.. versionadded:: 3.31

Specify a strategy for ordering a target's direct link dependencies
on linker command lines.  This property is initialized by the value of the
:variable:`CMAKE_LINK_LIBRARIES_STRATEGY` variable if it is set when a
target is created.

CMake generates a target's link line using its :ref:`Target Link Properties`.
In particular, the :prop_tgt:`LINK_LIBRARIES` target property records the
target's direct link dependencies, typically populated by calls to
:command:`target_link_libraries`.  Indirect link dependencies are
propagated from those entries of :prop_tgt:`LINK_LIBRARIES` that name
library targets by following the transitive closure of their
:prop_tgt:`INTERFACE_LINK_LIBRARIES` properties.  CMake supports multiple
strategies for nominally ordering direct and indirect link dependencies,
which are then filtered for `Toolchain-Specific Behavior`_.

Consider this example for the strategies below:

.. code-block:: cmake

  add_library(A STATIC ...)
  add_library(B STATIC ...)
  add_library(C STATIC ...)
  add_executable(main ...)
  target_link_libraries(B PRIVATE A)
  target_link_libraries(C PRIVATE A)
  target_link_libraries(main PRIVATE A B C)

The supported strategies are:

``REORDER_MINIMALLY``
  Entries of :prop_tgt:`LINK_LIBRARIES` always appear first and in their
  original order.  Indirect link dependencies not satisfied by the
  original entries may be reordered and de-duplicated with respect to
  one another, but are always appended after the original entries.
  This may result in less efficient link lines, but gives projects
  control of ordering among independent entries.  Such control may be
  important when intermixing link flags with libraries, or when multiple
  libraries provide a given symbol.

  This is the default.

  In the above example, this strategy computes a link line for ``main``
  by starting with its original entries ``A B C``, and then appends
  another ``A`` to satisfy the dependencies of ``B`` and ``C`` on ``A``.
  The nominal order produced by this strategy is ``A B C A``.

  Note that additional filtering for `Toolchain-Specific Behavior`_
  may de-duplicate ``A`` on the actual linker invocation in the
  generated build system, resulting in either ``A B C`` or ``B C A``.

``REORDER_FREELY``
  Entries of :prop_tgt:`LINK_LIBRARIES` may be reordered, de-duplicated,
  and intermixed with indirect link dependencies.  This may result in
  more efficient link lines, but does not give projects any control of
  ordering among independent entries.

  In the above example, this strategy computes a link line for ``main``
  by re-ordering its original entries ``A B C`` to satisfy the
  dependencies of ``B`` and ``C`` on ``A``.
  The nominal order produced by this strategy is ``B C A``.

Toolchain-Specific Behavior
^^^^^^^^^^^^^^^^^^^^^^^^^^^

After one of the above strategies produces a nominal order among
direct and indirect link dependencies, the actual linker invocation
in the generated build system may de-duplicate entries based on
platform-specific requirements and linker capabilities.
See policy :policy:`CMP0156`.

For example, if the ``REORDER_MINIMALLY`` strategy produces ``A B C A``,
the actual link line may de-duplicate ``A`` as follows:

* If ``A`` is a static library and the linker re-scans automatically,
  the first occurrence is kept, resulting in ``A B C``.
  See policy :policy:`CMP0179`

* If ``A`` is a shared library on Windows, the first
  occurrence is kept, resulting in ``A B C``.

* If ``A`` is a shared library on macOS or UNIX platforms, the last
  occurrence is kept, resulting in ``B C A``.