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
properties LINK_OPTIONS and INTERFACE_LINK_OPTIONS are propagated
to the device link step.
To control which options are selected for normal link and device link steps,
the $<DEVICE_LINK> and $<HOST_LINK> generator expressions can be used.
Fixes: #18265
