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.
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
Swift started the trend of piling language-specific target flags in
`cmLocalGenerator::AddLanguageFlags`. Other languages have added their
own under language-specific `Add<Lang>TargetFlags`.
I'm refactoring where Swift piles on its language-specific target flags
to match the pattern other languages are using.
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.
Split GenerateHeaderSetVerificationFile into three focused helpers:
- ResolveHeaderLanguage: determines the language for a header; returns
early for headers with an explicit LANGUAGE property (validated
against the supported set), and otherwise computes and caches the
target's default language using a lattice join (CXX > C) over target
sources and globally enabled languages.
- GenerateStubForLanguage: maps a resolved language to a stub file
extension (.c or .cxx) and creates the verification source.
- GenerateHeaderSetVerificationFile: orchestrates the above, moving
the SKIP_LINTING guard here and switching the return type to
cm::optional<std::string> so callers can distinguish "no file" from
an empty path.
No behavior change; only C and CXX are supported at this point.
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.
This adds the following new arrays, which together capture all direct
dependencies and interface dependencies of a target:
- linkLibraries
- interfaceLinkLibraries
- compileDependencies
- interfaceCompileDependencies
- objectDependencies
- orderDependencies
Fixes: #21995, #25213
The cmLinkImplItem class used to contain some additional members
to support the CMP0027 policy. Since the CMP0027 policy and those
associated members were removed, the cmLinkImplItem class has been
a plain wrapper around cmLinkItem with no additional members.
It is no longer needed and cmLinkItem can be used directly wherever
cmLinkImplItem was used previously.
When targeting the MSVC ABI, define `_MBCS` by default if the project
does not define `_SBCS` or `_UNICODE`. Visual Studio has long defined
one of the three character set macros automatically. For consistency,
define it when compiling for the MSVC ABI with other generators.
Add policy CMP0204 for compatibility.
Fixes: #27275
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
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
Visual Studio defines this automatically for `.dll` targets.
For consistency, define it when compiling for the MSVC ABI
with other generators. Add policy CMP0203 for compatibility.
Fixes: #27253
Now that generation can work with any way the state gets to the way it
is, just do the target enforcement at generation time. This allows PCH
reuse targets to be declared before or after targets which use them.
Also update `cmLocalGenerator` to use the methods now that they reliably
provide values rather than parallel construction.
The property settings set things up once, but nothing ensures that
post-reuse hookup that any property changes propagate. Instead, when
computing PDB information, if PCH reuse is enabled, just always use its
values.
Also drop enforcement at generate time of property value consistency as
it is now ignored when PCH reuse is in effect.
Additionally, if a target is PCH-reused, generate a PDB output directory
for it.
The `PchReuseFromIgnoreOwnProps` test failed previously because the
post-reuse link update of the consuming `PDB` properties are no longer
considered. The `PchReuseFromUseUpdatedProps` failed because the
post-reuse link did not update the copy of the properties added to
consuming reuse target properties.
Visual Studio doesn't use a `CMakeFiles` subdirectory for its support
directories. However, some codepaths expect to use paths which are
always under `CMakeFiles`. Add a mechanism to keep the path for such
files.
- Module documentation synced with other similar find modules.
- Added examples section.
- Added note about Swift Testing framework, which supersedes the XCTest.
- Added note about the XCTEST target property and synced docs a bit.
- Used word "commands" instead of "macros" or "functions".
Vito Gamberini
Brad King
Vito Gamberini
Matthew Woehlke
Baudouin Feildel
Evan Wilde
Marc Chevrier
Kyle Edwards
Mickaël Germain
Daniel Tierney
John Franklin Rickard
Craig Scott
AJIOB
Taylor Sasser
Martin Duffy
Ben Boeckel
Peter Kokot
Giacomo Rombaut