Ninja commit `7424d27c25` (Implement GNU jobserver pool mode,
2025-06-16) added a warning on stderr if `-j` is passed explicitly
while a jobserver is available. Update test expectations.
Splitting up the computation of common variables, module build
variables, and object build variables to make it a little easier to
focus on each one.
Updated tests to reflect updated flag order and updated object-build
description.
e4a37fbf15 Tests/RunCMake/Swift: Add CMP0195 behavior checks
b7a78568c3 CMP0215: Update NEW behavior to require CMP0157/CMP0195 to be NEW
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12407
Adding checks to ensure that CMP0195 has the desired effect. If the
Swift compiler is too old and does not include the module triple in the
emitted target info, we won't set `CMAKE_Swift_MODULE_TRIPLE` and end up
with the flat directory structure. In this case, these tests won't have
the expected layout.
Issue: #28021
Update CMP0215 to avoid attempting to iterate through the flags
looking for `-emit-module-path` ins the user-specified flags. We don't
do this anywhere else in the code. The existing implementation didn't
handle correctly parsing the flag so `-I blah/my-emit-module-path/` and
`-Xcc -emit-module-path ...` would both trigger it, result in the
compiler not emitting any module. Furthermore, it didn't include the
user-specified module path as part of the build graph resulting in an
incorrect build graph that would never resolve.
The only two appropriate layouts for the module are either the flat
binary module file with the name `<module-name>.swiftmodule`, or the
nested form with
`<module-name>.swiftmodule/<module-triple>.swiftmodule`. The noted
Swift-Syntax situation passes the explicit `-emit-module-path` to get to
the latter form. This form is automatically emitted by CMake when
CMP0195 is `NEW`, removing the need for the flag. The Swift project
generally recommends the nested directory structure since it gathers all
of the generated interface outputs from the compiler (textual swift
interfaces, swiftdoc, sourceinfo, and the binary swiftmodule file) in a
single place, and since it uses the module triple in the filename,
cleanly allows fat mach-o binaries on Apple platforms.
Fixes: #28021
The OLD behaviors of all policies are deprecated, but only by
documentation. Add an explicit deprecation diagnostic for policies
introduced in CMake 3.29 and below to encourage projects to port
away from setting policies to OLD.
Swift supports CodeView/PDB for Windows (with active development ongoing
to make it the default). It is currently usable but does not have the
same fidelity as DWARF, but can be sufficient for many use cases. The
user is able to control this via flags. Wire up the necessary support to
allow `TARGET_PDB_FILE` to be used with Swift/Swift-only targets.
Since commit b6367f723b (Swift/Ninja: Emit modules separately from
compilation, 2026-04-10) the compile and emit-module edges share the
same -output-file-map, which references a single module-level
.swiftdeps file. When ninja schedules both edges concurrently, both
swift invocations write that file and corrupt it.
Add the .swiftmodule output as an order-only dependency of the object
compile edge so the two edges within a target run sequentially.
Downstream targets are unaffected: they still unblock as soon as the
emit-module edge finishes, preserving cross-target parallelism.
Move the object-build WriteBuild call to after the emit-module block
so the order-only dep is added after modBuild is copied from objBuild,
avoiding a self-reference on the emit-module edge's own output.
Issue: #27748
Since commit b6367f723b (Swift/Ninja: Emit modules separately from
compilation, 2026-04-10) the .swiftmodule output moved from the
compile edge to a separate emit-module edge. The link edge does not
depend on the emit-module output, so ninja never runs the emit-module
edge when no other target in the build imports the module (e.g.
install-only targets).
Store the declared .swiftmodule output path during Swift object
statement generation and add it as an implicit dependency of the link
edge.
Issue: #27748
GetSwiftModuleName() returns the target name verbatim when
Swift_MODULE_NAME is not set, but hyphens are not valid in Swift
module identifiers. Replace them with underscores so that targets
like swift-syntax get module name swift_syntax automatically.
Issue: #27748
Since commit b6367f723b (Swift/Ninja: Emit modules separately from
compilation, 2026-04-10) the compile edge still appends
-emit-module -emit-module-path when emitModuleSeparately is active,
duplicating the emit-module edge. For targets with directory-style
module paths (CMP0195=NEW), this causes a file/directory conflict
that fails the build.
Guard -emit-module -emit-module-path on both the compile and
emit-module edges so they are not appended when the flags already
contain -emit-module-path (e.g. from the target's compile options).
Discovered building swift-syntax on Windows where the directory-style
path was overwritten by the flat path from the compile edge.
Issue: #27748
Add policy CMP0215 to emit `.swiftmodule` from a dedicated `-emit-module`
build edge for importable Swift targets in the Ninja generator.
Downstream targets can begin compiling as soon as the module interface
is ready, overlapping with upstream object compilation and linking.
When CMP0215 is NEW and CMP0157 is NEW, separate module emission is
enabled by default. The `Swift_SEPARATE_MODULE_EMISSION` target
property (initialized by the `CMAKE_Swift_SEPARATE_MODULE_EMISSION`
variable) can override this per target.
The compile edge still passes `-emit-module` so that swiftc continues
to produce `.swiftdoc`; only the `.swiftmodule` output moves to the new
edge.
Also fix swiftmodule dependency edges in cmNinjaNormalTargetGenerator
to use IsLanguageUsed instead of GetLinkerLanguage, so C/C++ targets
whose linker language propagated to Swift do not produce spurious
implicit dependencies.
Closes: #27748
Extract SetupResponseFile and ExpandRuleCommands helpers from
WriteCompileRule to allow reuse by new rule types.
Reorder flag appending in WriteSwiftObjectBuildStatement so that
-module-name and -module-link-name precede -emit-module, preparing
for a separate emit-module edge that shares common flags. Update
test regexes accordingly.
Issue: #27748
Since commit 56e5cea600 (Swift: Support module libraries with
command-line build systems, 2024-03-23, v3.30.0-rc1~245^2) we pass
`CMAKE_SHARED_LINKER_FLAGS` when linking Swift shared libraries if
CMP0157 is NEW. For consistency, pass `CMAKE_EXE_LINKER_FLAGS` when
linking executables. Add policy CMP0214 for compatibility.
Fixes: #26154
Update expected test output to account for the new format of diagnostic
messages. These changes were applied entirely by `sed` using the
following commands:
- `/Use -Wno-dev to suppress/s/-Wno-dev/-Wno-author/g`
- `s/Warning [\\][(]dev[\\][)]/Warning \\(author\\)/g`
- `s/CMake Deprecation Warning/CMake Warning \\(deprecated\\)/g`
This is not a complete fix, but covers a significant fraction of the
needed changes, and this commit is strictly automated changes.
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
Account for changes to upstream ninja:
* commit `5d93f2da28` (Add exit code to the failed target, 2024-12-03)
* commit `311bf93416` (Propagate jobs' exit codes to the ninja's exit code,
2024-12-03)
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
Setting `CMAKE_INSTALL_NAME_DIR` or the `INSTALL_NAME_DIR` on Swift
targets had no effect when CMP0157 was set to `NEW`. This was a result
of missing the `<TARGET_INSTALLNAME_DIR>` before the `<TARGET_SONAME>`.
Fix that and add a test to verify that the install name directory is
included in the install name.
Fixes: #26175
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().
Upstream ninja commit `8e6c741a4b` ("explain" debug prints just before
each command is run, 2022-01-06) changed the `ninja -d explain` output
for our test case. The `IncrementalSwift-second` case primarily needs
to match stdout, so update our stderr expectation to work for either
form of ninja's output.
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
By default, Ninja displays the full build command for the object which
is very verbose. Warnings are often lost in the noise, and compile
errors take some searching to find. If a build step fails, Ninja will
still print out the full build command, so there's no loss of useful
information.
Fixes: #25853
Executables that don't export a public API should not emit a
swiftmodule, but the swift modulename is observable from within the
program, so we should still set the module name on executable builds.
Fixes: #25710
Unlike C/C++, Swift compiles all sources in a module at once. This can
quickly overwhelm the commandline length limit on Windows, so it is
useful to place the source files in the response file.
Issue: #25572
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.
Brad King
Evan Wilde
Saleem Abdulrasool
Roman Lavrov
Fabrice de Gans
Matthew Woehlke
Robert MaynardandBrad King
AJIOB
Hanna Rusakovich
ClausKlein
Evan Wilde
Dave Abrahams
Jeremy Day