Encapsulate the shell escaping logic in `cmCommonTargetGenerator` and
represent launchers via a vector of strings (as is done with custom
commands, execute process commands, etc.) to make them easier to work
with.
This facilitates work in a future commit which will reuse this pathway.
Issue: #27598, #27402
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
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
Restore the ordering before the refactoring in commit 0f20ba5b68
(Ninja: Swift: Extract helpers and reorder module flags, 2026-04-10,
v4.4.0-rc1~273^2~1) to ensure the correct precedence with launchers.
Add regression tests.
Fixes: #27931, #27934
Move some target related enumeration types from `cmStateTypes.h` to a
new header, as these really aren't "state" types. Also, make
`TargetType` a strongly-typed enumeration.
In commit b65930a7a7 (Fortran: Add Fortran_BUILDING_INTRINSIC_MODULES
for building intrinsics, 2025-01-09, v4.0.0-rc1~223^2) we only
implemented the property for the Makefile generators. Implement it
for the Ninja generators too.
Fixes: #26803
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
Avoid bumping the file's mtime on every configure when its content
hasn't changed. Otherwise ninja sees it as modified and re-runs every
Swift compile edge that depends on it.
Observed in the Swift toolchain build (LLVM monorepo with swift as an
external project): a no-op reconfigure cascaded into hundreds of
unnecessary edges via per-target output-file-map.json mtime bumps.
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
Find places that are currently relying on diagnostic-specific message
types to issue diagnostics and replace these with calls to the new
diagnostic methods.
7ebb5687ab cmGeneratorTarget: use typename for `flag`
4a4986d28a cxxmodules: support command templates for BMI compilation
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11871
Some compilers (Clang) warn when using their BMI-only flag with `-c`.
Support a complete template for BMI compilation rather than an
additional flag to support such toolchains.
Fixes: #27600
Since commit 5898c8d2e0 (cxxmodules: Generate per-importer BMIs for
native targets, 2025-12-29, v4.3.0-rc1~43^2~1) we use synthetic targets
to perform per-importer BMI-only compilation of modules even from
in-project targets. However, our BMI-only compile lines are still
generated from the `CMAKE_CXX_COMPILE_OBJECT` rule variable, which
contains `-c` or equivalent. Clang expects `-c` and `--precompile` to
be mutually exclusive, leading to warnings, or errors with `-Werror`.
Follow up commit e5b1a23f27 (c++modules: Revert partial implementation
of per-importer BMIs for 4.3, 2026-02-27, v4.3.0-rc2~9^2) by reverting
the rest of the implementation from the 4.3 release. Work toward fixing
the implementation will proceed in post-4.3 development.
Issue: #25539
Issue: #27600
Issue: #27597
Each Rust source file given to a target is considered a separate crate
root. There's a concept of a "main crate root", which is the `.rs` file
that is given to the final linker phase in CMake. Other Rust source file
in a target are built as rlib separately.
The project can still build `.rs` files into object files by setting the
Rust_EMIT property on the desired source file.
To manage the generation step, introduce cmGeneratorFileSet and
cmGeneratorFileSets classes.
These reorganizations of the code are done in preparation of the
implementation of SOURCES file set type as well as user's file set types.
Issues: #27550, #27383
C++ module importers may have specific usage requirements that differ from
other importers of the same module, potentially requiring separate Built Module
Interfaces (BMIs) for compatibility. CMake creates synthetic targets to
generate and link usage-specific BMIs. This change extends CMake's per-importer
BMI generation to native targets in addition to imported targets.
`include-what-you-use` diagnostics, in practice, are specific to
the environment's compiler and standard library. Update includes
to satisfy IWYU for our CI job under Debian 13. Some patterns:
* Types named in virtual `override` signatures no longer require
includes since the overridden signature already names them.
* A function argument's type needs to be included even if its constructor
is called only by implicit conversion. For example, constructing a
`std::function` from a lambda now requires `<functional>`.
* Some prior mysterious `<type_traits>` inclusions are no longer required.
Create a single place to store target data to prevent duplication.
This moves `targetType` and `targetLabels` out of the snippet files
and into a target map in the `cmakeContent` file referenced by each
snippet.
Fixes: #27244
This commit allows to override a global or target-wide 'job pool'
property on a per-source basis.
It modifies the Ninja generator to first look into the source's
properties, and only use the target properties as a fallback.
The new `source` parameter to
`cmNinjaTargetGenerator::addPoolNinjaVariable` may be null, e.g. when
the function is called in context where there is no source (e.g. a
linking task).
Closes: #23994
Commit aafd771529 (cmNinjaTargetGenerator: use `GetObjectFileDir` where
possible, 2025-05-21) from !10812 accidentally converted the
`GetTargetDependInfoPath` from an always-absolute path to a
relative-for-ninja path. This works fine as everything ended up doing
`ConvertToNinjaPath` as necessary *except* the code which actually wrote
the file. That needs an absolute path in order to generate it in the
correct location.
Fixes: #26983
Tyler Yankee
Evan Wilde
Brad King
Vito Gamberini
Matthew Woehlke
Michael Kruse
Marc Chevrier
Saleem Abdulrasool
Roman Lavrov
Ben Boeckel
Baudouin Feildel
Daniel Tierney
Alex Turbov
Martin Duffy
John Parent
Bastien Montagne
Kitware Robot