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.
This allows use of `CMAKE_CURRENT_LIST_DIR`, `foreach(IN LISTS)`,
`if(VERSION_*)`, and more.
Note that generated filesets code already uses `if(VERSION_*)` and
requires CMake 2.8.3 in practice.
Improve the logic added by commit f0e67da061 (target_link_libraries: Fix
out-of-dir linking of a list of targets, 2020-01-14, v3.17.0-rc1~149^2)
to, while exporting targets, look up referenced target names in the
correct directory.
