Reapply the implementation in commits commits 77312cc6 (CUDA: Add
support for [CMAKE_]CUDA_LINKER_LAUNCHER, 2025-05-30,
v4.1.0-rc1~80^2~1) and cdf2a36f (HIP: Add support for
[CMAKE_]HIP_LINKER_LAUNCHER, 2025-05-30, v4.1.0-rc1~80^2).
Add a special case to expand the correct rule placeholder for these
languages, which is spelled `CMAKE_<LANG>_HOST_LINK_LAUNCHER`. Enable
the tests for these languages correctly. Re-document support under
CMake 4.5.
Fixes: #26967
The implementation in commits 77312cc6 (CUDA: Add support for
[CMAKE_]CUDA_LINKER_LAUNCHER, 2025-05-30, v4.1.0-rc1~80^2~1) and
cdf2a36f (HIP: Add support for [CMAKE_]HIP_LINKER_LAUNCHER, 2025-05-30,
v4.1.0-rc1~80^2) is broken, and the tests are wrongly configured
so as to never actually run. Revert the entire feature to avoid future
confusion, including documented support.
Enable the test for Fortran, which was added but untested by commit
d176a8c5ce (Fortran: Add support for [CMAKE_]Fortran_LINKER_LAUNCHER,
2025-05-26, v4.1.0-rc1~96^2), and whose implementation works.
Issue: #26967
Evaluate the XCODE_EMBED_<type> target property through the generator
expression evaluator before building the copy-files phase. Xcode shares
one copy-files build phase across all configurations, so the embedded set
cannot vary by configuration. Reject any expression whose result depends
on the configuration, matching the existing per-source diagnostic.
Fixes#28082
Process C++ module interface and partition units that are members of a
FILE_SET of type CXX_MODULES. moc is run on such units and its
generated output is compiled as a module implementation unit of the same
module, as its own scanned translation unit rather than folded into
mocs_compilation.cpp. Macro-less units get an empty placeholder; module
units and their dependencies are tracked in the autogen depfile and as
byproducts for correct incremental rebuilds.
This requires Qt 6.13, whose moc supports C++ module units. With older
Qt nothing can be generated for a module unit, so a meta-object macro
found in one is reported as an error rather than left to fail later in
the compiler or the linker. Such a unit is no longer handled as an
ordinary source, which also means its moc include directives are not
honored and AUTOUIC does not process it.
moc rejects a meta-object macro in a module implementation unit or a
private module fragment, and AUTOMOC does not work around that.
The name of a generated ui header follows the '#include' directive that
requests it, not the location of the .ui file. That was not written down,
and neither was the optional directory prefix such a directive may carry.
CMake nevertheless has to predict the name at configure time, in order to
register the generated header as a source of the targets in the directory.
The prediction assumes that the include prefix matches the location of the
.ui file relative to CMAKE_CURRENT_SOURCE_DIR, so it is wrong when the .ui
file lies outside of that directory, or lies in a subdirectory but is
included without a prefix.
Document both, along with the resulting symptoms, and point to Qt's
qt_add_ui() command, which takes the include prefix explicitly and
therefore needs no prediction at all.
Issue: #23523
Commit 680fbb112a (Autogen: Enable depfile support for Visual Studio and
Xcode generators) disabled the PRE_BUILD optimization when a depfile is
used, because a PRE_BUILD event cannot carry depfile dependencies. Since
then, every target with AUTOMOC or AUTOUIC enabled gains an
'<ORIGIN>_autogen' and an '<ORIGIN>_autogen_timestamp_deps' target,
which the Visual Studio generators turn into two extra projects per
target in the generated solution.
Attach the autogen custom command to the origin target instead. The
custom command still carries the depfile, and the dependencies of the
origin target provide the ordering that
'<ORIGIN>_autogen_timestamp_deps' provides otherwise, because MSBuild
builds all referenced projects before any step of the referencing
project.
Use the conditions of the PRE_BUILD event, so that the
'<ORIGIN>_autogen' target keeps existing wherever it existed before
depfiles were enabled for the Visual Studio generators. In particular,
projects that name the target in add_dependencies() keep working.
Ninja and the Makefile generators keep the separate targets. Extra
targets have no cost for them, and '<ORIGIN>_autogen' has always existed
there.
The Xcode generator gained the same two targets per origin target in
4.4, but attaching the custom command there needs some more thoughts on
the per-config timestamp file first: Xcode rejects targets whose sources
vary by configuration, and with AUTOGEN_BETTER_GRAPH_MULTI_CONFIG the
timestamp file is per configuration.
Fixes: #28034Fixes: #28033
17094eb572 ALIAS: Add test for generator expressions with ALIAS targets
5f8cc64695 ALIAS: Add support for add_dependencies for ALIAS targets
79e421b053 ALIAS: Add support for target_* commands
3b327695aa ALIASED_TARGET: Make property read-only
a121419908 ALIAS: Add support for set_property and set_target_properties commands
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12207
The ALIAS_GLOBAL property is read-only, so ALIASED_TARGET should be as
well. Even when set, there is no way to read the property value, so this
change gives an explicit error for users.
Currently, target properties related to file sets are specific to file set
type (for example "SOURCE_SETS"). This raises some concerns:
1. For each new file set type, 6 new properties are created which need a lot
off documentation update
2. there is no "generic" way to discover file sets information
The new target properties (FILE_SET_TYPES, FILE_SETS_<TYPE>,
and INTERFACE_FILE_SETS_<TYPE>), in conjunction with the file sets
properties, enable a complete generic file sets information discovery.
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
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
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
Always create `<target>_verify_*_header_sets` targets and the aggregate
`all_verify_*_header_sets` utility targets when the corresponding
property is enabled, even when no matching headers exist.
When headers exist, an OBJECT library is created as before. When no
headers are found, a UTILITY target is created instead to avoid
warnings from tools like Xcode's libtool about empty static libraries.
Update documentation with `.. versionchanged:: 4.4` directives, update
tests, and add a release note.
Fixes: #27685
Extend header set verification to support Objective-C and Objective-C++.
The supported-language table grows to {"C", "CXX", "OBJC", "OBJCXX"}
and the lattice join is updated so OBJCXX is chosen when both CXX and
OBJC sources are present. GenerateStubForLanguage emits .m/.mm stubs
and the relevant OBJC/OBJCXX standard properties are copied to the
verification target.
Add OBJC/OBJCXX test cases conditioned on CMake_TEST_OBJC, isolated in
dedicated project files to avoid affecting language inference for
unrelated targets. Update property documentation and add a release note.
Several problems with this feature came up while testing 4.3.0-rc1.
These include both broken stdlib distributions and regressions in our
implementation of the feature since CMake 4.2.
Revert commit 70c1f0f43d (Experimental: Remove import std experimental
gate, 2026-02-04, v4.3.0-rc1~61^2) except for its incidental fixes.
Remove the 4.3 release notes related to `import std`.
Rotate the experimental gate's UUID.
Issue: #27426
Issue: #27597
Issue: #27626
Issue: #27635
Brad King
Marc Chevrier
Tyler Yankee
Tor Arne Vestbø
Joerg Bornemann
Vito Gamberini
Arha Gatram
Michael Kruse
Evan Wilde
Roman Lavrov
Maykol Irigoyen
Baudouin Feildel
Mickaël Germain
Vito Gamberini
Ralf Habacker
Garrett Campbell
Martin Duffy