In debug builds, we assert and abort to give more useful crashes for
development (i.e., instead of triggering UB). Otherwise, we get the
optimization benefits of `unreachable()` (or the older
platform-specific fallbacks per `cm/utility`).
a887fda85e WINDOWS_EXPORT_ALL_SYMBOLS: Improve performance with Clang toolsets
6d6e58a15e WINDOWS_EXPORT_ALL_SYMBOLS: Fix support for Visual Studio with ClangCL
ca1dc92e36 WINDOWS_EXPORT_ALL_SYMBOLS: Fail explicitly if `nm` fails to start
03e56cd338 Tests: Add cases covering `nm` handling for WINDOWS_EXPORT_ALL_SYMBOLS
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12327
Move some target related enumeration types from `cmStateTypes.h` to a
new header, as these really aren't "state" types. Also, make
`TargetType` a strongly-typed enumeration.
65fbe16e16 NAG Fortran: Use `-xldarg @` to pass response files to the linker
6dc46638f4 NAG Fortran: Fix response file flag for creating archives
b53d3c7cc1 Makefiles: Make logic enabling CUDA device link response files more specific
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !12013
Since commit 10d6c3a635 (NAG: Pass response files through front-end to
the linker, 2018-08-01, v3.13.0-rc1~244^2) we use `-Wl,@` instead of `@`
in order to pass the response file through the `nagfor` compiler driver
to the linker. However, this is not needed for the archiver. Create
a separate rule variable so we can use different response file flags
for archiving and linking.
Issue: #23577
Since commit b6367f723b (Swift/Ninja: Emit modules separately from
compilation, 2026-04-10) the .swiftmodule output moved from the
compile edge to a separate emit-module edge. The link edge does not
depend on the emit-module output, so ninja never runs the emit-module
edge when no other target in the build imports the module (e.g.
install-only targets).
Store the declared .swiftmodule output path during Swift object
statement generation and add it as an implicit dependency of the link
edge.
Issue: #27748
Add policy CMP0215 to emit `.swiftmodule` from a dedicated `-emit-module`
build edge for importable Swift targets in the Ninja generator.
Downstream targets can begin compiling as soon as the module interface
is ready, overlapping with upstream object compilation and linking.
When CMP0215 is NEW and CMP0157 is NEW, separate module emission is
enabled by default. The `Swift_SEPARATE_MODULE_EMISSION` target
property (initialized by the `CMAKE_Swift_SEPARATE_MODULE_EMISSION`
variable) can override this per target.
The compile edge still passes `-emit-module` so that swiftc continues
to produce `.swiftdoc`; only the `.swiftmodule` output moves to the new
edge.
Also fix swiftmodule dependency edges in cmNinjaNormalTargetGenerator
to use IsLanguageUsed instead of GetLinkerLanguage, so C/C++ targets
whose linker language propagated to Swift do not produce spurious
implicit dependencies.
Closes: #27748
Each Rust source file given to a target is considered a separate crate
root. There's a concept of a "main crate root", which is the `.rs` file
that is given to the final linker phase in CMake. Other Rust source file
in a target are built as rlib separately.
The project can still build `.rs` files into object files by setting the
Rust_EMIT property on the desired source file.
The TU for Rust is a crate, not per-source. `rustc` expects entry file
to TU as input, and cannot work with object files. So we need to have
one-step build/link in most cases, similar to what old Swift was doing.
Issue: #25492
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Create a single place to store target data to prevent duplication.
This moves `targetType` and `targetLabels` out of the snippet files
and into a target map in the `cmakeContent` file referenced by each
snippet.
Fixes: #27244
Considerations of Ninja's control sequences was not considered in
30fb5b1b22 (Ninja: add COMMENT to build statement descriptions,
2024-05-01) via !9484. Escape both newlines and dollar signs.
Fixes: #27181
Fix a bug in the split build model where we generate a dependency on the
swiftmodule of a target that does not emit a swiftmodule.
This fix drops the erroneous swiftmodule dependency edge, avoiding the
broken dependency graph. Incremental builds still work with the new
model because of the swiftmodule dependency edges between Swift
compilation steps.
Fixes: #26922
This commit allows to override a global or target-wide 'job pool'
property on a per-source basis.
It modifies the Ninja generator to first look into the source's
properties, and only use the target properties as a fallback.
The new `source` parameter to
`cmNinjaTargetGenerator::addPoolNinjaVariable` may be null, e.g. when
the function is called in context where there is no source (e.g. a
linking task).
Closes: #23994
Revert infrastructure from commit 8bcf9c7a3e (Add support of "LINKER:"
prefix for artifact creation flags, 2024-10-12, v4.0.0-rc1~522^2~1).
It is not needed to populate legacy placeholders with empty strings.
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.
Marc Chevrier
Tyler Yankee
Brad King
Chuck Atkins
Vito Gamberini
Matthew Woehlke
Baudouin Feildel
Simon Maertens
Roman Lavrov
Kyle Edwards
Ayush Singh
Martin Duffy
Ben Boeckel
Evan Wilde
Bastien Montagne
Vince Dupuis
Kitware Robot
Alex Turbov
Aditya Vidyadhar Kamath
Dave Abrahams
Evan Wilde
Craig Scott