Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`, now with "east const" enforcement.
Use `clang-format` version 18.
* 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.
Issue: #26123
In commit 375e6fdbbe (Link step: use linker dependency linker file,
2023-04-19, v3.27.0-rc1~126^2) we added the `-Wl,--dependency-file,...`
flag for the Ninja generator in a code path shared with the file-api.
This flag is a build system implementation detail and should not be
exposed to file-api clients. Move it to a Ninja-specific code path.
Fixes: #26498
The following variables now support the LINKER: prefix:
* CMAKE_SHARED_LIBRARY_CREATE_<LANG>_FLAGS
* CMAKE_SHARED_MODULE_CREATE_<LANG>_FLAGS
* CMAKE_<LANG>_LINK_FLAGS
Extend commit d27fe9dfba (AIX: Add option to archive shared libraries,
2024-06-18) to update the Ninja generator to support the new
`AIX_SHARED_LIBRARY_ARCHIVE` feature.
Fixes: #26332
Place `.swiftmodule` files a subdirectory named after the configuration.
Fixes: #25864Fixes: #25997
- Swift/RunCMakeTest.cmake:
- CMP0157-OLD was enabled for Xcode, where it works.
- A test was added that verifies .swiftmodule's are generated into
separate directories with multi-config generators.
- Tests/SwiftOnly/CMakeLists.txt: tests were added that validate that
cross-subdirectory module dependencies (via target_link_libraries)
work.
Splitting the Swift build into an object build and a separate link step,
instead of building and linking in one step. The immediate benefit is
LSP support because we are able to emit compile-commands for Swift files
now. Additionally, it is possible to specify flags to the compile step,
enabling folks to emit C and C++ headers from their Swift builds for
C/C++ interop, without needing custom commands. Eventually, this gives
us a path toward working object libraries.
Object Libraries:
- Object libraries don't work today because CMake doesn't emit targets
for object libraries into the Ninja build file.
- tl;dr: Object libraries work if they aren't WMO. Still need work to
make WMO'd object libraries work.
Object libraries still don't completely work with this patch because,
while we emit the targets, the `TARGET_OBJECTS` generator expression
expansion has a separate mechanism for determining what the names of
the objects are based on the input source files, so targets that
depend on an object library built with a whole-module optimization
will depend on objects based on the name of the source file instead
of the actual emitted object file.
These features require being able to accurately model wholemodule builds
though, because we actually need to track object files and WMO affects
what objects are emitted. For that, we require CMP0157 use the NEW
policy. When it's OLD, we have to fall back on the old behavior and
cannot provide object libraries or the compile-commands for LSP.
Issue: #25308
Offer the capability, through variable `CMAKE_LINKER_TYPE`, as well as
the target property `LINKER_TYPE` to specify which linker must be used.
The implementation of this capability is specified by variables specific
to the language and linker type: `CMAKE_<LANG>_USING_LINKER_<TYPE>`.
Some definitions are provided as part of `CMake`.
For example, to select the `LLVM` linker rather than the standard one,
the type `LLD` should be specified through the variable `CMAKE_LINKER_TYPE`.
And, on `Apple`, `Linux` and some environments on `Windows`, the variable
`CMAKE_<LANG>_USING_LINKER_LLD` has value `-fuse-ld=lld`. And for `Windows`
environments based on `MSVC`, where the linker is used directly, the tool
`lld-link.exe` will be used rather than `link.exe`.
Fixes: #19174, #24254, #24990
`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().
