Since commit 7abd3137b7 (Linking: Optionally reorder direct dependencies
from LINK_LIBRARIES, 2024-09-19, v3.31.0-rc1~53^2) the strategy name
`PRESERVE_ORDER` has led users to expect that it strictly preserves
order. While the part of the link line generation logic controlled by
`LINK_LIBRARIES_STRATEGY` does preserve order, it is not the last step.
Toolchain-specific de-duplication can cause the order to change on the
actual link line generated in the build system.
Rename the strategies:
* `PRESERVE_ORDER` => `REORDER_MINIMALLY`
* `REORDER` => `REORDER_FREELY`
The new names make it clear that reordering is always possible, just to
varying degrees. Update the `LINK_LIBRARIES_STRATEGY` documentation to
clarify that the strategies do not directly control the final link line.
Fixes: #26400
Issue: #26271
Traditionally CMake generates link lines by starting with the direct
link dependencies specified by `LINK_LIBRARIES` in their original order
and then appending indirect dependencies that the direct dependencies
do not express. This gives projects control over ordering among
independent entries, which can be important when intermixing flags
and libraries, or when multiple libraries provide the same symbol.
However, it may also result in inefficient link lines.
Add support for an alternative strategy that can reorder direct link
dependencies to produce more efficient link lines. This is useful
for projects that cannot easily specify their targets' direct
dependencies in an order that satisfies indirect dependencies.
Add a `CMAKE_LINK_LIBRARIES_STRATEGY` variable and corresponding
`LINK_LIBRARIES_STRATEGY` target property to select a strategy.
Fixes: #26271
Compute link information for all C++ targets which support
modules instead of just those which may provide modules, as
they may import modules as well. This captures `OBJECT` libraries using modules
which otherwise do not have link steps.
Fixes: #25592
2c6ec6de15 Link to transitive dependencies on stub libraries only on some linkers
dd4a6dff92 Link explicitly to private transitive dependencies on stub libraries
5f1bbdb3b3 Tests: Enable RunCMake.RuntimePath test on more platforms
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !9050
We represent stub libraries, e.g., for CUDA, using imported `SHARED`
library targets with only `IMPORTED_IMPLIB`, and no `IMPORTED_LOCATION`,
to indicate that the stub file is meant only for linkers and not dynamic
loaders. See commit 7351d590ee (cmTarget: Add a way to represent
imported shared library stubs, 2023-07-17, v3.28.0-rc1~344^2) and commit
fc6508921c (cmComputeLinkInformation: Restore soname lookup for
non-imported targets, 2023-12-05, v3.28.0~4^2).
If a shared library is linked to a stub, it has a `NEEDED` field
populated with the `SONAME` found in the stub. When a dependent target
links to such a shared library, some linkers want to find a library file
on disk and load it to see what symbols it provides. This is necessary
for linkers that enforce `--no-allow-shlib-undefined`. On hosts with
only the stub library installed, e.g., with only the CUDA toolkit
development package, the real runtime library corresponding to the
stub's `SONAME` may not even exist, so no `-rpath-link` flag can help
linkers find it. Pass the stub library to linkers explicitly so they
can find it without searching.
In commit 7351d590ee (cmTarget: Add a way to represent imported shared
library stubs, 2023-07-17, v3.28.0-rc1~344^2) we accidentally stopped
passing the SONAME of a non-imported SHARED library to our runtime
search path ordering logic. Unfortunately I have not found a way to add
a test case for this, but it at least shouldn't regress existing tests
or those added by that commit.
Simplify commit 2c7acd34e2 (cmComputeLinkInformation: add `OBJECT`
libraries as link items, 2023-07-24, v3.28.0-rc1~279^2) using the
existing local variables.
Since commit b6a5382217 (Ninja: depend on language module information
files directly, 2023-02-10, v3.27.0-rc1~502^2), the return value of
`cmCommonTargetGenerator::GetLinkedTargetDirectories` must account for
linked object libraries because they may provide modules (#25112).
These were added by commit b665966933 (cmComputeLinkInformation: track
OBJECT library dependencies, 2023-07-22, v3.27.1~5^2). However, targets
named by `$<TARGET_OBJECTS:...>` sources are also needed (#25365).
The latter were added by commit 22da18b995 (Fortran: Restore support for
TARGET_OBJECTS providing modules, 2023-10-27, v3.28.0-rc4~9^2) and
commit 035302b7e3 (cmComputeLinkDepends: also copy the target from
object link items, 2023-10-27, v3.28.0-rc4~9^2~2). However, their
approach added link entries not actually specified by projects. It also
incorrectly re-used `cmComputeLinkDepends::AddLinkObject` for object
library targets when it is meant for their individual object files.
These problems caused additional regressions (#25417). Revert the
implementation parts of those commits and leave behind an assertion and
comment to help avoid the mistake in the future. Instead, track targets
named by `$<TARGET_OBJECTS:...>` sources with a dedicated member.
Issue: #25112
Issue: #25365Fixes: #25417
Co-authored-by: Ben Boeckel <ben.boeckel@kitware.com>
22da18b995 Fortran: Restore support for TARGET_OBJECTS providing modules
64d9240564 cmComputeLinkInformation: skip over linking to items for object purposes
035302b7e3 cmComputeLinkDepends: also copy the target from object link items
861876b936 Tests/ObjectLibrary: fix comment
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Acked-by: scivision <michael@scivision.dev>
Merge-request: !8923
d870a47e23 Tests/FortranModules: add a test for iface Fortran sources
e3d511fb9c Tests/FortranModules: also test INTERFACE targets with Fortran sources
978b68d3bb add_custom_target: Fix regression with Fortran sources
619aca80ae Tests/FortranModules: add a test case for #2522345513c1a69 Tests/FortranModules: move issue 25112 fix from FortranOnly
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8814
Since commit 74b1d6caf3 (cmComputeLinkInformation: compute link info for
module-using targets, 2023-09-05, v3.27.5~7^2) we accidentally try to
compute link information for custom targets if they have Fortran
sources. For module dependencies, we only need to consider target types
that can compile.
Fixes: #25252
* fortran-object-libraries-release:
cmComputeLinkInformation: compute link info for module-using targets
cmGeneratorTarget: support config-independent Fortran source queries
Targets which contain C++ module or Fortran sources need to participate
in link information unconditionally regardless of whether they actually
have link artifacts or not.
Fixes: #25223
In commit b6a5382217 (Ninja: depend on language module information files
directly, 2023-02-10), introduced via !8197, language-specific module
information files (`CMakeFiles/<target>.dir/<lang>Modules.json`) files
were added as real dependencies to the dyndep collation steps.
Previously, the behavior was to inform the collator of all possible
targets and search for the files manually ignoring those which did not
exist with ordering enforced by depending on the linker output of all
dependent targets. This behavior could lead to stale information being
used (e.g., if a target stops providing any targets) and also did not
reliably build everything needed on rebuilds. Afterwards, the internal
computation changed the dependency from all possible targets to an exact
set of "these targets might have modules" query, however one that did
not include `OBJECT` libraries since do not have `LinkEntry` items
internally (their objects are instead treated as source files).
As a stopgap measure, track `OBJECT` libraries in a separate list and
query them explicitly when gathering targets which may have interesting
information. Future work can add `LinkEntry` items to represent these
targets once all `LinkEntry` consumers have been audited to make sure
they are not surprised by any `OBJECT` library entries.
Fixes: #25112
Shared library stubs can be used for linking, but not at runtime.
Their role is similar to import libraries on Windows, so represent
their location with the `IMPORTED_IMPLIB` target property.
Fixes: #24940
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 15.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
Fixes: #24315
This fix ensures the following pattern is correctly handled:
$<LINK_GROUP:group_feat,$<LINK_LIBRARY:lib_feat,mylib>>
With:
CMAKE_LINK_GROUP_USING_group_feat = "—START_GROUP" "—END_GROUP"
CMAKE_LINK_LIBRARY_USING_lib_feat = "—PREFIX" "—LINK <LIBRARY>" "—SUFFIX"
Before the fix, we get the following generation:
—START_GROUP —PREFIX —LINK /path/to/mylib —END_GROUP —SUFFIX
—END_GROUP and —SUFFIX are in the wrong order
After the fix, we get the correct order:
—START_GROUP —PREFIX —LINK /path/to/mylib —SUFFIX —END_GROUP
Variable CMAKE_LINK_(LIBRARY|GROUP)_USING_<FEATURE>_SUPPORTED is evaluated
only if CMAKE_<LANG>_LINK_(LIBRARY|GROUP)_USING_<FEATURE>_SUPPORTED is not defined.
This new behavior enable to activate a feature globally on a platform and to disable
it for some compilers and languages.
To be more consistent between genex and variables as well as
the forecomming LINK_GROUP genex, rename variable *_LINK_USING_<FEATURE>*
in *_LINK_LIBRARY_USING_<FEATURE>*
Brad King