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
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
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
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.
The target properties `CUDA_SEPARABLE_COMPILATION` and `CUDA_PTX_COMPILATION`
now aren't mutually exclusive and can now be used together on the same
target.
Optionally enable this infrastructure through an undocumented
`CMAKE_EXPERIMENTAL_CXX_MODULE_DYNDEP` variable. Currently this is
experimental and intended for use by compiler writers to implement their
scanning tools. Warn as such when the feature is activated. Later when
compilers provide the needed scanning tools we can enable this variable
from our corresponding compiler information modules. It is never meant
to be set by project code.
When enabled, generate a build graph similar to what we use for Fortran
module dependencies. There are some differences needed because we can
scan dependencies without explicit preprocessing, and can directly
compile the original source afterward.
Co-Author: Ben Boeckel <ben.boeckel@kitware.com>
These changes are in preparation of compiler generated dependencies support
for Makefiles generators
* compiler output and dependency target can be different for Makefiles generators
* resolve inconsistency naming for dependency file place-holder
Repeated invocations of `cmake ... -DCMAKE_C_COMPILER=gcc` should not
trigger a "You have changed variables" message even though the cache
value of CMAKE_C_COMPILER changes from '/path/to/gcc' to 'gcc'.
Make repeated invocations of `cmake ... -DCMAKE_C_COMPILER=gcc;-pipe`
not trigger the warning by comparing the compiler name portion of the list to
the compiler being used.
Since commit 0f150b69d3 (AIX: Explicitly compute shared object exports
for both XL and GNU, 2019-07-11, v3.16.0-rc1~418^2~2) we always export
all symbols from shared libraries by default. Add a new target property
called `AIX_EXPORT_ALL_SYMBOLS` that can be explicitly set to OFF to
suppress this behavior and export no symbols by default.
Fixes: #20290
Set the MinTypeNameLength option to an impossibly high value in order
to limit the diagnostics to iterators. Leave new expressions and cast
expressions for later.
This cleans up the new options that were added to support Swift. This
was not released, and the proper support approach that we settled upon
does not require as much specialised support.
This adds the placeholders that are needed to merge the swift partial
modules. It permits generating the rules necessary to actually merge
the partial modules emitted for a partial compilation.
When building a swift object, we emit a partial swiftmodule and swiftdoc
that must be merged at the end. However, in order to do that, we need
to enumerate the swiftmodules and swiftdocs. As a result, the path must
be known to CMake. Rather than hardcoding the rules into CMake, create
a source property that we can query. This will allow us to create a
final placeholder to emit the merge rule.
Issue: #18800
This allows us to set the proper link name for the Swift library
(soname). Because this needs to be passed to the object being compiled,
we need to create a new placeholder so that it can be sent along to the
frontend. Default to the target name unless it is explicitly provided.
Add a new `SWIFT_MODULE_NAME` property that defaults to the target name.
This is needed as otherwise, the first source file determines the module
name.
Issue: #18800
The swift compilation model requires all sources for the module to be
listed for the compiler to type check across them. Provide a
placeholder to allow enumerating the remainder of the swift sources in a
target for the language compile rule.
Issue: #18800
Add `CMAKE_SYSROOT_COMPILE` and `CMAKE_SYSROOT_LINK` variables to as
operation-specific alternatives to `CMAKE_SYSROOT`. This will be useful
for Android NDKs that compile and link with different sysroot values
(e.g. `r14` with unified headers).
Co-Author: Florent Castelli <florent.castelli@gmail.com>
Refactoring in commit b29425f7 (cmLocalGenerator: Populate a container
of mappings for replacements, 2016-10-09) broke substitution of this
placeholder by storing the wrong key in the new replacement map.
Use the proper key, `CMAKE_<LANG>_COMPILER_ARG1`.
AJIOB
Baudouin Feildel
Robert MaynardandBrad King
Ayush Singh
Martin Duffy
Ben Boeckel
Kitware Robot
Marc Chevrier
Evan Wilde
Bobby D Reynolds
Raul Tambre
Robert Maynard
Fred Baksik
Daan De Meyer
Regina Pfeifer
Saleem Abdulrasool
Cengizhan Pasaoglu
Pavel Solodovnikov
Daniel Pfeifer
Zack Galbreath
Stephen Kelly