Add initial support for exporting (install only, for now) Common Package
Specification (https://cps-org.github.io/cps/) format package
descriptions. This has some limitations, such as not supporting
generator expressions (as these cannot be portably exported), and only
partially supporting transitive dependencies, but should be usable for
at least some simple cases. (Actually, $<LINK_ONLY> is theoretically
supportable, but is not yet implemented.)
This still needs tests; these will be added in the next commit. Other
potential improvements include support for language-specific compile
definitions and inferring some package properties from project
properties. Additionally, there is no module support yet; this is partly
pending on having a tool agnostic format for providing the necessary
information.
In order to support generation of Common Package Specifications, the
mechanisms CMake uses to export package information need to be made more
abstract. The prior commits began this refactoring; this continues by
(actually) restructuring the classes used to generate the actual export files.
To minimize churn, this introduces virtual base classes and
diamond inheritance in order to separate logic which is format-agnostic
but depends on the export mode (build-tree versus install-tree) from
logic which is format-specific but mode-agnostic.
This could probably be refactored further to use helper classes instead,
and a future commit may do that, however an initial attempt to do that
was proving even more invasive, such that this approach was deemed more
manageable.
While we're at it, add 'const' in more places where possible.
Use clang-format to fix placement of const qualifiers to be consistently
right of the typename. The inconsistency was getting annoying,
especially as the following refactor changes a lot of methods and
sometimes adds const. (Being inconsistent within a file is not ideal,
but in some cases there was inconsistency within single lines!)
In order to support generation of Common Package Specifications, the
mechanisms CMake uses to export package information need to be made more
abstract. As a first step toward this, refactor cmInstallExportGenerator
so that logic specific to config.cmake and Android .mk lives in separate
subclasses.
While we're at it, clean up the code style a bit and try to use moves a
bit more consistently.
This is step 1 of 2. The next step will refactor the individual file
generators along similar lines, which will also involve creating
additional classes for format-agnostic logic that is shared between
build-tree and install-tree variants.
Slightly tweak the logic that tests if a user can consume exported
targets to immediately report the actual version required, rather than
potentially giving the consumer false hope by reporting that 2.8 is
required, only to immediately run another check that requires a more
recent CMake version. (Note that the two-level check is presumably
needed because CMake < 2.8 wouldn't understand VERSION_LESS.)
Since commit c16acd35b3 (GenEx: Add support for custom transitive link
properties, 2024-05-09, v3.30.0-rc1~82^2) evaluation of
`TRANSITIVE_LINK_PROPERTIES` by `install(EXPORT)` enables discovery of
missing dependencies on INTERFACE libraries that we did not previously
diagnose. This regressed existing projects that relied on such
non-diagnosis. Although commit 2fc9e482a9 (Evaluation of
TRANSITIVE_LINK_PROPERTIES isn't considered a usage, 2024-07-05) fixed
this, it also made a significant change to the `UseTo` infrastructure
that may have other subtle effects. Replace the fix with an approach
that explicitly models suppression of the relevant diagnostics.
Fixes: #26108
The files generated by `install(EXPORT)`, `export()`, and
`install_jar_exports()` commands are known to work with policies
as of CMake 3.29, so enable them in sufficiently new CMake versions.
Teach the `$<TARGET_PROPERTY:...>` generator expression to check for a
new `TRANSITIVE_LINK_PROPERTIES` property in the target's link
closure to enable transitive evaluation of named properties through
the link closure, including entries guarded by `$<LINK_ONLY:...>`.
Fixes: #20416
Teach the `$<TARGET_PROPERTY:...>` generator expression to check for a
new `TRANSITIVE_COMPILE_PROPERTIES` property in the target's link
closure to enable transitive evaluation of named properties through
the link closure, excluding entries guarded by `$<LINK_ONLY:...>`.
Issue: #20416
In commit c6e6861e63 (install(EXPORT): Export find_dependency() calls,
2023-11-07, v3.29.0-rc1~439^2~1) we made the calls `REQUIRED`. However,
a dependency is only required if the dependent package is required.
`find_dependency` already forwards the `REQUIRED` mark, and also already
marks the dependent package as not found if the dependency is missing.
Fixes: #25756
This allows for transitive modules to work because
`$<COMPILE_ONLY>`-wrapped dependencies do not end up in the
`linked-target-dirs` collator property. Test suite exported property
tests updated to account for the change.
The files generated by `install(EXPORT)`, `export()`, and
`install_jar_exports()` commands are known to work with policies
as of CMake 3.28, so enable them in sufficiently new CMake versions.
Include the name of the `EXPORT` in the filename when generating export
information for C++ modules. This allows the same directory to be used
for multiple sets of C++ module-using targets.
For `export(TARGETS)` uses, generate a name based on the hash of the
concatenation of the target names involved with the `export()` call.
Fixes: #25609
The files generatd by `install(EXPORT)` and `export()` commands
are known to work with policies as of CMake 3.27, so enable them
in sufficiently new CMake versions.
When consuming exported targets which contain C++ modules, the consuming
project must be able to recompile BMI files using the original target's
flags. This is because a module source may use some private target usage
requirement but not want to propagate it to consumers. To facilitate
this, export the private information as necessary for consumers to be
able to perform the BMI compilations.
After b665966933 (cmComputeLinkInformation: track `OBJECT` library
dependencies, 2023-07-22), introduced in !8645 as a fix for #25112,
`OBJECT` libraries were tracked in a separate member to reduce the risk
of further regressions. This commit prepares consumers to handle
`OBJECT` libraries once they start appearing as link items.
The files generatd by `install(EXPORT)` and `export()` commands
are known to work with policies as of CMake 3.26, so enable them
in sufficiently new CMake versions.
This generator expression is the inverse of `LINK_ONLY` and only coveys
usage requirements for the purposes of compilation. Its intended use is
to avoid needing to export targets that do not have link usage
requirements (e.g., header-only libraries) when used by another target.
It will also be used to represent private usage requirements on exported
C++ module-containing targets in the future.
Eventually there should be logic to collapse nesting of
`$<COMPILE_ONLY>` and `$<LINK_ONLY>` when generating instances of
either. A TODO is left in the code for this case.
See: #15415
FILE_SET was introduced in CMake 3.23, so install(EXPORT) puts it
behind a version gate. However, this results in the include directories
not being picked up by older versions of CMake. Fall back to
set_property(APPEND) for versions of CMake older than 3.23.
Fixes: #24787
The files generatd by `install(EXPORT)` and `export()` commands
are known to work with policies as of CMake 3.25, so enable them
in sufficiently new CMake versions.
The files generatd by `install(EXPORT)` and `export()` commands
are known to work with policies as of CMake 3.24, so enable them
in sufficiently new CMake versions.
Refactoring in commit 8c65b7042e (cmExportFileGenerator: Simplify
collection of targets missing from export set, 2022-04-11,
v3.24.0-rc1~281^2) accidentally dropped the behavior change from
commit 0ad2a1c181 (Export: Never treat private link libraries as
public package dependencies., 2013-09-24, v3.0.0-rc1~559^2).
Restore the behavior and add a test.
Fixes: #23838
The files generatd by `install(EXPORT)` and `export()` commands
are known to work with policies as of CMake 3.23, so enable them
in sufficiently new CMake versions.
