`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.
e08ba229ee CMake code rely on cmList class for CMake lists management (part. 1)
51b0d45d91 cmExpandList and cmExpandLists rely on cmList class
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8423
We add a function in cmNinjaNormalTargetGenerator.cxx to check for the state of the option (as it was done for Makefile). This will be checked to add or not the `$LINK_PATH` and `$LINK_LIBRARIES` to the Ninja file.
The default behavior is adding those libraries.
Fixes: #24681
Swiftmodules act like headers for Swift, but are generated by the
compiler while building the module. Unlike headerfiles in a pure C/C++
world, where the compiler generates the appropriate depfile. We don't
have We're
already adding the swiftmodule as an output from swift-linked targets,
but aren't using that on inputs.
This dependency edge is most important for static libraries in
incremental builds. Suppose we have two static libraries, A, and B, and
an executable E. B "links" against A, and E links against B. In a C/C++
environment, the library link dependency edge will run from E to both A
and B, but there won't be an edge from B to A. If A is changed, the only
way this should affect B is if the public interface changes, in which
case, the headers will also change. The dep file contains the header
link, so Ninja will rebuild B when appropriate. With Swift in an
incremental build, B sees the order-dependency on A, but A already
exists. If A is changed in a way that changes the public interface, the
swiftmodule will change, but since we don't track it, we don't rebuild
B, resulting in the final executable to fail to link.
In order to handle determining the swiftmodule name to add to the ninja
dependency graph, we'll need to be able to compute the swiftmodule name
for the dependency target, not just the current target. This patch
refactors the computation of the module name out of inaccessible lambdas
and into static functions that can compute the swiftmodule name from the
generator and the target.
This patch adds support for tracking the swiftmodules for executables
exporting symbols.
This fixes a bug in the earlier implementation around emitting the
swiftmodule. Previously, the code would use
`CMAKE_EXE_EXPORTS_Swift_FLAG` to inject the `-emit-module`, and module
path information into the `CMAKE_Swift_LINK_EXECUTABLE` rule. Because
Swift skips the build step and only runs during the link phase, these
flags were injected in `cmNinjaNormalTargetGenerator::ComputeLinkCmd`
instead of `cmLocalGenerator::GetTargetFlags` where it is done normally.
Unfortunately, injecting in `ComputeLinkCmd` didn't do anything because
we have a `linkCmd` so `ComputeLinkCmd` exits early, before the
EXE_EXPORT flags get added to the link command.
Instead of playing with that flag, CMake checks
`CMAKE_Swift_LINK_EXECUTABLE_WITH_EXPORTS` and uses that as the link
rule if it exists and falls back on `CMAKE_Swift_LINK_EXECUTABLE`. I've
defined that variable in terms of `CMAKE_Swift_LINK_EXECUTABLE` with the
necessary additional flags for emitting the swift module instead. This
has the same end effect as the desired behavior, but simplifies things a
bit.
Since we're generating the swiftmodule for executables with exports,
I've also updated the dependency graph to include the swiftmodule as an
output in the build dependency graph if the executable has exports.
Tests updated:
- RunCMake/NoWorkToDo:
Ensure that the build graph does not result in unnecessary rebuilds
with exporting executables.
- SwiftOnly:
Ensure that we can consume functions defined in the executable by a
library getting linked into said executable.
Swift doesn't emit swiftmodules for executables, so we shouldn't put it
in dependency graph. Ninja sees the "missing" dependency and always
tries to rebuild/re-link the target.
Swift is used as the linker for non-swift files because it needs to pull
files like swiftrt.o in when swift symbols are present to ensure that
the swift runtime is linked.
The swift driver uses clang as the underlying linker, which pulls in
crtbegin.o and friends when appropriate, so using Swift as a linker for
C/C++ libraries is fine.
The output-file-map was getting passed to all Swift invocations,
regardless of whether or not we generated one. This patch changes it so
that we only include the output-file-map in the Swift compiler
invocation if we have actually generated the file.
With how things were before, mixed Swift/C++ libraries would result in a
broken ninja file. `cpp.cpp.o` was emitted by the compiler, but was
also being included in the `linkBuild.Outputs` list, so it was being
emitted by multiple targets.
The fix checks that the source language is Swift before adding it to the
list of additional outputs. If it is Swift, this isn't a problem. If it
isn't Swift, we don't include it in the list of outputs.
On the other side, the C++ file was also being passed as a source file,
which the Swift compiler can't compile. So we add the C++ object file as
an explicit dependency and the object file is then added to the list of
Swift sources.
In commit 9a0d5a828a (Ninja: add /DEF: flag to linker call, 2012-03-10,
v2.8.8~22^2~7) the logic should have been added to `GetTargetFlags` in
place of the older logic in that method from commit 7cef36c628 (ENH: add
the ability to generate custom commands for a language that is not
supported by an IDE, 2004-10-21, v2.4.0~2655).
Fixes: #23570
Add link flags during the "device compile" step.
Enabled the relevant tests. The disable reasons regarding separable compilation
were outdated and the actual failure case was device link flags support.
There's no reason to allocate the cmNinjaLinkLineDeviceComputer on the heap.
We can also assume the link language as CUDA in cmLocalGenerator::GetDeviceLinkFlags().
Move the logic for appending cubin afterwards, so the check can simply be
empty().
With the Makefile generator the option is now at the front instead of being
intermixed with the actual bins.
Currently, this feature is only supported on ELF platforms. So, the property
LINK_WHAT_YOU_USE will be ignored for other plateforms.
Moreover, flags and commands are now controled by CMake variables.
Fixes: #20174
The `GetSourceFilePath` method is meant only for compiled sources, and
automatically handles converting it to a path for the Ninja build
manifest. Rename the method to clarify both.
If the shared object name contains spaces, they need to be properly
escaped, or link command will fail.
This was already done for soname symlink creation in commit 13c92b4a30
(Ninja: Fix creation of library symlinks in folders with spaces,
2019-05-20, v3.15.0-rc1~87^2).
Fixes: #20331
For NVCC the compiler takes care of device linking when passed the "-dlink"
flag.
Clang doesn't support such magic and requires the buildsystem to do the work
that NVCC does behind the scenes.
The implementation is based on Bazel's device linking documentation:
7cabcdf073/third_party/nccl/build_defs.bzl.tpl (L259)Closes: #20726
In commit 99ed39b011 (Ninja Multi-Config: Make link response files
per-config, 2020-07-15, v3.17.4~3^2), we added the target directory to
the response file under the mistaken assumption that two different
targets with the same name could be in different directories. However,
this causes the path to the response file to be too long to fit on a
command line. Take the path back out, while leaving in the per-config
split.
Fixes: #21050
