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
By specifying CODEGEN as an argument to add_custom_command the
custom command will be added to a codegen build target.
The intent is to provide a convenient way for users to get
their generated files without having to build the whole project.
This can be helpful for code analysis tools which can be useful
for IDEs and CI.
Most generators now support this character after escaping and quoting
cleanups over time. Disallow it only on generators that do support it.
Fixes: #25604
The generated `cmake_install.cmake` script no longer blindly tries to
create files `install_manifest_<component-name>.txt` that partly
consists of the verbatim name of a component, which might contain
characters that are not supported on the platform / filesystem.
Instead, if the component's name contains a (possibly) problematic
character its MD5 hash will be used:
`install_manifest_<component-hash>.txt`
Since commit f593b354da (PCH: Add support for multi architecture iOS
projects, 2020-04-02, v3.18.0-rc1~414^2) we use per-arch .pch files
even when compiling for just the host architecture on macOS arm64.
This breaks with compilers that do not support `-Xarch_` flags, such
as GCC. Avoid using per-arch .pch files in single-architecture builds.
Fixes: #25514
Issue: #20497
Wire up the flags needed to support module libraries built and used with
Swift. We need to pass `-bundle` to the linker when linking module
libraries on Darwin, and we need to pass `-export-dynamic` to the linker
when emitting an executable that exports symbols on Linux. This patch
wires up `CMAKE_SHARED_MODULE_CREATE_Swift_FLAGS` and
`CMAKE_SHARED_MODULE_LOADER_Swift_FLAG` on Darwin, and hooks up
`CMAKE_EXE_EXPORTS_Swift_FLAG` on Linux in order to support passing
things correctly.
We can't expose `CMAKE_EXE_LINKER_FLAGS` to Swift, as it contains flags
that the Swift compiler doesn't recognize, but the other
language-specific variables are safe to expose.
801ae06952 LINKER_TYPE: Support MOLD only on GCC versions that support it
939ac5287e LINKER_TYPE: fix spelling error in message
922883782b LINKER_TYPE: Document that linker tool should be in the PATH
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9334
5b8e9e068f Restore support for TARGET_OBJECTS in link interfaces with unity builds
1313c78a9c Tests: Update RunCMake.TargetObjects cmake_minimum_required version
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !9279
5b8e9e068f Restore support for TARGET_OBJECTS in link interfaces with unity builds
1313c78a9c Tests: Update RunCMake.TargetObjects cmake_minimum_required version
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !9279
This was broken by commit df08c37a42 (cmGlobalGenerator: Add unity/pch
sources after computing compile features, 2024-02-02, v3.28.3~1^2~1^2),
and 3.28.2's commit 76b5383123 (cmGlobalGenerator: add unity sources
after computing target compile features, 2024-01-01, v3.28.2~17^2~1).
The problem is very similar to that fixed by commit 4e8f24e977 (PCH:
Clear link interface cache when adding PCH object to it, 2022-01-24,
v3.23.0-rc1~44^2~9). Generalize that fix.
Fixes: #25696
Use the same flags Xcode adds for `XROS_DEPLOYMENT_TARGET`. They are
`-target arm64-apple-xros1.0` and `-target arm64-apple-xros1.0-simulator`,
where `1.0` is the deployment target version.
Fixes: #25188
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
40dc13b242 cmNinjaTargetGenerator: PCH files do not need dyndep
f61c64cd1c cmLocalGenerator: prevent scanning of PCH source files
ea8c37b759 Tests/CXXModules: add a test which scans a PCH-using source
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !9032
Add a `CMAKE_Swift_COMPILATION_MODE` variable and corresponding
`Swift_COMPILATION_MODE` target property to control the compilation
mode. Select among `wholemodule`, `singlefile`, and `incremental`.
Add policy CMP0157 to remove the default `-wmo` flags in favor of the
abstract setting.
Issue: #25366
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
6546aa2a2a ci: Add HIP job using CUDA on NVIDIA GPUs
18158bf81c HIP: Add support for NVIDIA GPUs
127b6fa06b HIP: Add CMAKE_HIP_PLATFORM variable to specify GPU platform
90e23f40ee Tests/HIP/WithDefs: Clean up test case
9ebdf3281f Tests/HIP/ArchitectureOff: Cover HIP_ARCHITECTURES initialization
cfec29196e ci: Add CUDA 11.8 to HIP 5.5 image
26470eb987 ci: Put HIP GPU platform in CMake_TEST_HIP
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8817
