| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Due to a bug on LLD linker for ELF binaries, deduplication should
occur only if CMP0156 and CMP0179 are NEW.
Fixes: #26447
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
Revert commit 502610733f (Ensure imported targets in sibling dirs are
deduplicated, 2024-09-15, v3.31.0-rc1~92^2). Also revert the change
from a copy of the logic made by commit cd418d4bb6 (Static libraries
de-duplication: keep first occurrence, 2024-09-29, v3.31.0-rc1~30^2).
The logic was de-duplicating based on the target name rather than based
on the library file path.
Fixes: #26371
Issue: #26284
|
|
|
|
| |
Fixes: #26335
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Print results of the main ordering algorithm before platform-specific
filtering by `CMAKE_<LANG>_LINK_LIBRARIES_PROCESSING`.
|
|
|
|
| |
This will be useful for testing.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes: #26284
|
| |
|
|
|
|
|
| |
* enhance OVERRIDE handling
* Update wording
|
| |
|
| |
|
|
|
|
| |
Fixes: #24504, #25954
|
|
|
|
|
|
|
|
| |
Since commit 1e49880472 (cmGeneratorTarget: Avoid boolean trap in usage
requirement lookup, 2021-12-08, v3.23.0-rc1~245^2) we have clarified
the distinction between compile-only and link-only usage requirements.
Rename the `LinkInterfaceFor` enum to `UseTo` to clarify that its role
is to specify the purpose of usage requirements.
|
|
|
|
|
| |
This is the local generator in the evaluation context, not that of
the current target/property pair.
|
|
|
|
| |
Fixes: #25416
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
beb1393f8f Merge branch 'revert-exact-collation-depends-3.27' into fortran-objects-as-sources-fix
a033dce326 Makefiles: provide, but do not consume, "forward linked" target dirs
7cd0adab1b cmCommonTargetGenerator: use modules from linked object-referenced targets
1175f1c874 LinkItem: track `cmSourceFile` instances for external objects
d2fa56772f Ninja: support "forwarding" modules from other targets
ec1e589bec Ninja: Revert exact collation dependencies for 3.27
06df59b930 cmCommonTargetGenerator: return forward linked target dirs too
f8729ab366 cmLocalUnixMakefileGenerator3: handle object-referencing Fortran modules
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !8989
|
| |
| |
| |
| |
| | |
The target may be required in order to provide Fortran modules, so track
the source file so that the target may be looked up when needed.
|
|\ \
| |/ |
|
| | |
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
d7988ff6b8 Merge branch 'backport-target-objects' into target-objects
1814853081 cmCommonTargetGenerator: Drop unused local variable
377b78aef9 cmComputeLinkInformation: Simplify recording OBJECT libraries as link items
50fdaf8f1f cmComputeLinkInformation: Track targets named by TARGET_OBJECTS sources
0e26bd334d cmCommonTargetGenerator: Factor out GetLinkedTargetDirectories loop body
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Reviewed-by: Ben Boeckel <ben.boeckel@kitware.com>
Merge-request: !8974
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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: #25365
Fixes: #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
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Some platforms, Apple or Windows for instance, do not require to duplicate
static libraries to resolve mutual dependencies. Moreover, Xcode version 15
emits a warning if a library is duplicated.
On Windows, enable a better control of libraries order.
Fixes: #20722, #25297
|
| | |
| | |
| | |
| | |
| | | |
This refactoring is done in preparation of the possibility to configure
the deduplication of the libraries as well as the order on the link command.
|
|\ \ \
| |/ /
|/| /
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Continue b665966933 (cmComputeLinkInformation: track OBJECT library
dependencies, 2023-07-22) which added explicitly listed `OBJECT`
libraries to the list of targets which the collator needs to consider.
Now also consider targets which provide objects directly to the target
via a `$<TARGET_OBJECT>` source lists.
Also add tests which use target objects directly and through an
`INTERFACE` library with target objects in its own sources.
Fixes: #25365
|
| | |
|
|/
|
|
|
|
| |
`include-what-you-use` diagnostics, in practice, are specific to
the environment's compiler and standard library. Update includes
to satisfy IWYU for our CI job under Debian 12.
|
| |
|
|
|
|
| |
This avoids using casts everywhere when dealing with the sizes.
|
|
|
|
| |
This is to prepare for making the graph use `size_t`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We evaluate `LINK_LIBRARIES` and `INTERFACE_LINK_LIBRARIES` for two purposes:
* Constructing the link line.
* Collecting usage requirements.
We evaluate `INTERFACE_LINK_LIBRARIES` separately for each purpose in
order to support the `$<LINK_ONLY:...>` generator expression used to
express private link dependencies of a static library. Previously we
only evaluated `LINK_LIBRARIES` for linking, and used that result for
collecting usage requirements too. Therefore `$<LINK_ONLY:...>` does
not work in `LINK_LIBRARIES`.
With the introduction of `INTERFACE_LINK_LIBRARIES_DIRECT`, evaluation
of `LINK_LIBRARIES` now needs to distinguish these two cases in order to
honor link dependencies encountered through `$<LINK_ONLY:...>` without
also exposing other usage requirements through private dependencies of a
static library. Revise internal infrastructure to distinguish the two
cases when evaluating `LINK_LIBRARIES`. Make the information available
in code paths for `INTERFACE_LINK_LIBRARIES_DIRECT` and `LINK_ONLY`.
Defer actually using the information to later commits.
Issue: #22496
|
|
|
|
| |
Fixes: #23121
|
| |
|
|
|
|
|
|
| |
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>*
|
|
|
|
|
|
| |
To enable the management of incompatible $<LINK_LIBRARY> declarations,
add LINK_LIBRARY_OVERRIDE and LINK_LIBRARY_OVERRIDE_<LIBRARY> target
properties.
|
|
|
|
|
|
|
|
| |
This generator expression offers the capability, for the link step, to
decorate libraries with prefix/suffix flags and/or adding any specific flag for each
library.
Fixes: #22812, #18751, #20078, #22703
|
| |
|
| |
|
|
|
|
|
| |
Any target that might need to link to hip code needs the `hip::device`
target
|