This patch makes the `Swift_MODULE_DIRECTORY` property behave more like
the other output directory properties, allowing generator expressions
and fixing the behavior with multi-config generators.
Issue: #26010
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.
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.
Add public symbols to SubA and SubB. The test was broken due to a
broken build graph. The build graph expects libraries to emit the
`.lib` file. `link.exe` only emits the implib if the library exports at
least one symbol. Because these two libraries were empty, nothing was
generated.
Fixing by adding a public symbol to both libraries.
Issue: #25573
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
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
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.
correct Xcode generator Swift definitions
original code was defining GCC_PREPROCESSOR_DEFINITIONS which is valid only for C languages
add definitions to SWIFT_ACTIVE_COMPILATION_CONDITIONS when Swift language is used in the target
add test in SwiftOnly
for old Xcode (<8.0), append defines to cflags so it ends up in OTHER_SWIFT_FLAGS
Fixes: #23637
Extend the `SwiftOnly` test to cover the fix in commit 3ddd7f3576
(enable_language: Fix test for working compiler with CMP0126 NEW
behavior, 2021-07-15), as that commit did for the `CSharpOnly` test.
Fixes: #22451
Since commit 2026915f8f (Swift: Propagate Swift_MODULE_DIRECTORY as include
directory, 2020-02-03, v3.18.0-rc1~547^2) we internally call
`GetAllConfigCompileLanguages` on all directly linked targets without
checking if they are interface libraries that don't compile at all.
That violates an internal assumption and assertion.
Fixes: #20977
Teach include directory computation for Swift to implicitly propagate
the `Swift_MODULE_DIRECTORY` of all linked targets as include
directories. This is required to ensure that the swiftmodule of a
linked target is accessible to the compiler of the current target.
Fixes: #19272
The check added in commit b06f4c8a74 (Swift: disallow WIN32_EXECUTABLE
properties, 2019-05-31, v3.15.0-rc1~9^2) makes sense only for
executables because the `WIN32_EXECUTABLE` property is defined only for
them. Running the check on other target types, particularly those that
do not link such as INTERFACE libraries, violates internal assumptions.
In particular, `GetLinkerLanguage` should not be called on such targets.
Fixes: #19528
Create a new CMAKE_Swift_LANGUAGE_VERSION variable to specify the
SWIFT_VERSION attribute in a generated Xcode project. Ideally this
would be a `<LANG>_STANDARD` property but since Swift support is
very minimal we should reserve that property for more complete
treatment later.
Issue: #16326
Allow the `Swift` language to be enabled with the Xcode generator for
Xcode >= 6.1. Reject it on other generators and with older Xcode
versions. Since Apple is the only vendor implementing the language
right now, the compiler id can be just `Apple`.
