| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Fixes: #18316
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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:
https://github.com/tensorflow/tensorflow/blob/7cabcdf073abad8c46e9dda62bb8fa4682d2061e/third_party/nccl/build_defs.bzl.tpl#L259
Closes: #20726
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
#pragma once is a widely supported compiler pragma, even though it is
not part of the C++ standard. Many of the issues keeping #pragma once
from being standardized (distributed filesystems, build farms, hard
links, etc.) do not apply to CMake - it is easy to build CMake on a
single machine. CMake also does not install any header files which can
be consumed by other projects (though cmCPluginAPI.h has been
deliberately omitted from this conversion in case anyone is still using
it.) Finally, #pragma once has been required to build CMake since at
least August 2017 (7f29bbe6 enabled server mode unconditionally, which
had been using #pragma once since September 2016 (b13d3e0d)). The fact
that we now require C++11 filters out old compilers, and it is unlikely
that there is a compiler which supports C++11 but does not support
#pragma once.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
Add the placeholders needed to support compiling Swift code.
|
| |
|
|
|
|
| |
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
|
| |
|
|
| |
Found via `codespell -q 3 -I ../cmake-whitelist.txt`.
|
| |
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Automate with:
git grep -l '#include <cm_' -- Source \
| xargs sed -i 's/#include <\(cm_.*\)>/#include "\1"/g'
git grep -l '#include <cmsys/' -- Source \
| xargs sed -i 's/#include <\(cmsys\/.*\)>/#include "\1"/g'
git grep -l '#include <cm[A-Z]' -- Source \
| xargs sed -i 's/#include <\(cm[A-Z].*\)>/#include "\1"/g'
|
| |\
| |
| |
| |
| |
| |
| | |
db61cd5d cmRulePlaceholderExpander: Remove unused member RuleLauncher
b7771078 Comment ExpandRuleVariables calls not preceded by launcher insertion
c58a5198 Makefile: Restore RULE_LAUNCH_COMPILE generation on compilation rules
|
| | | |
|
| |/ |
|
|
|
Implement cmLocalGenerator::ExpandRuleVariables in terms of the new
class for source compatibility and to reduce diff noise in this commit.
|
