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
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
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
`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.
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 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.
Create a brand new implementation of `cmTarget::GetMappedConfig` which
prioritized a target's `IMPORTED_CONFIGURATIONS` as the 'source of
truth' for what configurations are available. In particular, this means
that configuration selection when `IMPORTED_CONFIGURATIONS` is set does
not depend on the library type in any manner. The fallback logic also
uses a more consistent 'usability' criteria that should result in more
consistent configuration selection, particularly for `INTERFACE`
targets.
The previous implementation is retained as a separate method for users
requesting the OLD behavior.
Fixes: #27022
Add the concept of "origin" to cmTarget. For now, only CPS targets get a
unique origin, but this might be expanded in the future. This will allow
us to implement different behaviors based on a target's origin.
In particular, this has been requested as a means of addressing #26998
and #27022.
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`, now with "east const" enforcement.
Use `clang-format` version 18.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
Issue: #26123
By specifying CODEGEN as an argument to add_custom_command the
custom command will be added to a codegen build target.
The intent is to provide a convenient way for users to get
their generated files without having to build the whole project.
This can be helpful for code analysis tools which can be useful
for IDEs and CI.
This requires knowing when a generated header is public, which we can
model using file sets. Add policy CMP0154 to treat generated sources
as private by default in targets with file sets. Generated public
headers can be specified in public file sets.
Fixes: #24959
Issue: #15555
We need to be able to construct BMIs that will be usable from the client
modules for the target importing the module, so create BMI-only
compilation rules for `IMPORTED` targets to create these BMIs.
`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 12.
It is a normal target, but will end up copying its internals from
another target. Keep track of this state so that such copying can only
occur when intended.
C++ modules are going to introduce a third concept of "synthesized"
targets, so update logic where needed to avoid assuming "not imported?
must be normal".
Also add an accessor method to perform queries against the visibility.
C++ modules have two variants which are of importance to CMake:
- `CXX_MODULES`: interface modules (those using `export module M;`,
`export module M:part;`, or `module M:internal_part;`)
- `CXX_MODULE_HEADER_UNITS`: importable header units
Creating C++ modules or partitions are *not* supported in any other
source listing. This is because the source files must be installed (so
their scope matters), but not part of usage requirements (what it means
for a module source to be injected into a consumer is not clear at this
moment). Due to the way `FILE_SET` works with scopes, they are a perfect
fit as long as `INTERFACE` is not allowed (which it is not).
5fa15ec9f3 Help: Document that target_sources defines [INTERFACE_]HEADER_SETS
c5d4812f20 cmTarget: make HEADER_SETS and INTERFACE_HEADER_SETS read-only
05783b168d cmFileSet: store visibility with the fileset
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7168
Vito Gamberini
Marc Chevrier
Brad King
Daniel Tierney
Ben Boeckel
Craig Scott
Taylor Sasser
Matthew Woehlke
Daniel Pfeifer
Kitware Robot
Vitaly Stakhovsky
Aditya Vidyadhar Kamath
Juan Ramos
Martin Duffy
Orkun Tokdemir