The logic to select an imported configuration handled the case when
`IMPORTED_CONFIGURATIONS` was missing, but assumed that if it was
present, it was non-empty, which could cause CMake to crash if that
happens. (To be fair, I believe this would never happen for imports
generated by CMake.) Adjust the logic slightly to follow the same code
path when `IMPORTED_CONFIGURATIONS` is empty as is taken if it's
missing.
Fixes: #28065
In debug builds, we assert and abort to give more useful crashes for
development (i.e., instead of triggering UB). Otherwise, we get the
optimization benefits of `unreachable()` (or the older
platform-specific fallbacks per `cm/utility`).
CPS provides "default targets" as a user convenience which can be linked
by specifying only the package name. CMake implements this via a utility
`INTERFACE` target. However, because it is not namespaced, this is not a
valid requirement, which prevents exporting anything linking to this
target to CPS.
Work around this by introducing a new (internal) target property which
replaces a target with its link interface targets at export time.
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.
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.
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.
Move a bunch of low-level member initialization from `cmTarget` to
`cmTargetInternals`, and in particular, to inline default member
initializers where possible. This gives us the advantages of the latter
with no overhead, as the compiler will elide generating DMI code for
those members that are unconditionally initialized in the ctor. (We were
getting the same optimization already for members that were initialized
twice in the `cmTarget` ctor, but without the benefits of DMIs.)
Mostly, this means we have assurance, via the DMIs, that POD members are
initialized without having to verify whether there is explicit code to
do so, while retaining not paying for double initialization.
Also, because it just gets moved into place, change `cmTarget`'s ctor to
take the target name by value.
Usage effects describe the relationship between a provider and a
consumer of C++ module interface units. They encompass the flags and
features used to construct BMIs for those units. If the usage effects of
a provider and consumer match, then the provider's BMI may be reused
as-is. If they do not match, then a synthetic target describing the
interface units with the consumer's usage effects applied must be
created.
This commit makes three major changes to how usage effects are reified
in CMake. The first is simple, usage effect hashes now use compile
options and features as the input to their hash instead of the consumer
name. A simply warning flag filter is also applied, mostly to
demonstrate the mechanism. This is the "correct calculation" for usage
effects.
The second is more impactful, usage effects now entirely replace the
compile options of providers with those of consumers if unmatched.
Compile definitions, includes, and links remain unchanged. This is
necessary to ensure successful builds, but is a tricky semantic change.
The third is mostly source-facing, the discovery model for CxxModule
synthetic targets is no longer the global target namespace. Instead,
non-synthetic targets manage their synthetic derivatives. Every target
maintains a usage effect-keyed cache of synthetic targets. When
determining if a synthetic target is necessary, a given provider checks
for compatibility with itself, then for presence in the cache, and if
the cache misses a new synthetic target is created.
Fixes: #27597
Add and use a couple helper functions for issuing policy warnings. This
improves consistency and allows some simplification of many call sites.
(One or two instances in particular are greatly simplified.)
Add new diagnostic categories CMD_POLICY and CMD_EXPERIMENTAL, both as
children of CMD_AUTHOR. Use the former when issuing policy warnings. Use
the latter when issuing experimental feature warnings.
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
Find places that are currently relying on diagnostic-specific message
types to issue diagnostics and replace these with calls to the new
diagnostic methods.
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.
Some projects might get unlucky and have targets which collide in the
sha3-512 hash (truncated to 4) in a directory which also collides in the
same way (easily done by sharing it). Note such problems as potentially
colliding and offer potential remedies.
Also add a test which generates the error.
Closes: #27465
Add support for PRIVATE header sets, analogous to the existing
INTERFACE header sets support. A key difference between the two is
the way they handle build and usage requirements. INTERFACE
header sets rely on the original target's INTERFACE, whereas PRIVATE
header sets copy across various properties from the original target.
Generated files need special handling for PRIVATE header sets.
Add a dependency on the original target to the verification target to
ensure such generated files will exist.
Fixes: #23448
CMake 4.1 and earlier did not issue an error if an imported shared library target
was missing an IMPORTED_IMPLIB property and nothing used that imported
library. There was no code path checking for the CMP0111 NEW behavior. Since
b626843d71 (fileAPI: Output all INTERFACE and IMPORTED targets, 2025-09-13),
we now include all imported targets in the file API replies, and that does trigger
that check. We need to tolerate such imported targets to preserve backward
compatibility, and to avoid issuing errors for problems in targets likely to be
coming from outside the project and beyond the developer's control.
Fixes: #27496
Adds support for "symbolic" components, which represent feature-level
capabilities of a package that do not correspond to actual build targets.
These are modeled as pseudo-targets, using the INTERFACE type as a base,
and can be queried via:
get_target_property(... <tgt> "SYMBOLIC")
This enables consumers to declare requirements on optional features
(e.g., SSL support) even when they do not map to concrete targets.
Fixes: #27187
The recently introduced CMP0200 warnings could lead to a crash when
encountering targets with empty configuration values. Avoid calling
substr on an empty `string_view`.
Fixes: #27204
CMake historically has forced an `objects[-<CONFIG>]/<TARGET_NAME>`
subdirectory under an `OBJECT` library installation's `OBJECTS
DESTINATION` which may be unwanted. Support skipping this component
with a target property.
The recently introduced CMP0200 improved configuration selection, but
did not correctly implement case-insensitivity. Add some additional case
smashing to ensure that matching is not case sensitive. Improve the test
which was passing due to falling back to the first listed configuration
rather than selecting a matching configuration.
Marc Chevrier
Brad King
Matthew Woehlke
Tyler Yankee
Tom Osika
Vito Gamberini
Arha Gatram
Vito Gamberini
Roman Lavrov
Baudouin Feildel
Daniel Tierney
John Franklin Rickard
Ben Boeckel
Martin Duffy
Craig Scott
Taylor Sasser
Joerg Bornemann
Alex Turbov