c09f8d27cd cxxmodules: compute link information for C++ module-consuming targets
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Reviewed-by: Ben Boeckel <ben.boeckel@kitware.com>
Merge-request: !9154
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 #25223
45513c1a69 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
b665966933 cmComputeLinkInformation: track OBJECT library dependencies
a99b87a628 Tests/RunCMake/CXXModules: add a test for issue #25112
2870a67540 Tests/FortranOnly: add a test case for issue #25112
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !8645
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>*
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
In preparation of support of genex $<LINK_LIBRARY:...>, propagate
cmComputeLinkDepends::LinkEntry instances to ensure to have, when needed,
all attributes attached to the link item.
