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
The nested Swift module structure is recommended for Swift projects.
This structure has an outer directory called
`<Swift_MODULE_NAME>.swiftmodule` that contains generated files for the
interface. The binary swift modules, textual swift interface, and other
supplemental outputs that make up the interface to a Swift library all
go in this outer directory with the Swift module triple as the filename
followed by the appropriate file extension based on what that file
contains.
Issue: #19284
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.
Also factor out testing that's common across Xcode and Ninja.* generators.
- Ninja expected output files were extended to accept directories named
after the configuration in paths.
- Tests that previously ran with Ninja were allowed to run with Ninja
Multi-Config.
- Swift/RunCMakeTest.cmake:
- Checks for conditions where little or no testing could be done
were moved to the top of the file, with return()s to limit nesting
of the remainder of the code ("Early bailouts").
- CMP0157 tests, which were being performed for all generators, were
factored out into a block at the top of the file.
- RunCMake_TEST_OPTIONS is set initially for all multi-config
generators and list(APPEND)'ed-to in each block() where it was previously
set() and unset().
Top-level code only works as part of executables, which breaks when
`CMAKE_TRY_COMPILE_TARGET_TYPE` is set to `STATIC_LIBRARY`. This patch
fixes the test to something agnostic between executables and libraries
while still verifying that we can import types from the standard
library.
Fixes: #25984
This was accidentally removed when the command templates were
reorganized to introduce the new policy. Restore the flag in the shared
library creation to ensure that we emit the import libraries to the
correct location.
The `-static` is important for the emission of the module as it is
serialized into the swiftmodule which then is used by the Swift frontend
to decide how to link to the symbol (via the GOT or not, or the IAT on
Windows). This repairs building static libraries with Swift on Windows.
The swift toolchain leaves output files untouched
if there are no meaningful input changes; without
restat, this causes ninja to needlessly rebuild
targets that are not actually out-of-date
Fixes: #25496
Swift compile commands need to have all source files in the module
specified in the compile command or LSP systems will report errors on
missing types that are defined in other source files in the same module.
Issue: #25491
The CMP0157 old behavior omitted the output-file-map after the Swift
build split because we stopped calling `EmitSwiftDependencyInfo` when we
could not split the build because we didn't call
`WriteObjectBuildStatement`. If we can't split the build, then we still
need to include the OFM information to not break incremental builds.
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
Ensure that we're actually trying to rebuild libB when the public
interface for libA changes. Without handling the swiftmodule dependency
edge correctly, we would only get a linker error because libA didn't
have the symbol that libB depended on. With the fix, we get a proper
compiler error because ninja knows to rebuild the intermediate libB
when the public interface of libA changes. This is more actionable.
Swift doesn't emit swiftmodules for executables, so we shouldn't put it
in dependency graph. Ninja sees the "missing" dependency and always
tries to rebuild/re-link the target.
Currently, the compiler does not synthesize the correct entry point for
the application and passing the subsystem flag does not work the same
way with the Swift linker language. Add a check to prevent the
application of `WIN32_EXECUTABLE` to Swift executables until they can be
properly supported. This will prevent the need for a future policy
change.
Closes: #19325
It's relatively complex to determine in advance if a Xcode, SDK,
and Deployment Target configuration is capable of running Swift.
For example the following combinations do not work:
* deployment target < OS X 10.9
* Xcode 6.2 and macosx10.9 SDK
* Xcode 7 Beta 6 and macosx10.10 SDK
Until we found out how to query Xcode for Swift support in a reliable
way, the RunCMake.Swift test cases will be restricted to negative ones.
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`.
Evan Wilde