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.
In commit 55e4753bbb (Refactor cmTargetExport removing
InterfaceIncludeDirecories, 2021-07-20, v3.22.0-rc1~337^2~1) the storage
of `INCLUDES DESTINATION` was moved into each target. However, a target
may be installed in multiple exports, and their `INCLUDES DESTINATION`
should not be mixed.
Convert the IncludeDirectoriesEntries vector to a map and modify access
function to store the directories lists with respect to cmExportTarget
object. This fixes error when the same target is exported more than once
via different exports and each for consequent export its include
directories list grows. Add a test for this case.
Fixes: #23183
9a48012f93 Configure CMake itself with policies through CMake 3.22
a5a9687799 export: Increase maximum policy version in exported files to 3.22
a9ffded98c Add deprecation warnings for policies CMP0097 and below
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !6948
This was accidentally left out of commit 736663deed (Begin 3.23 release
versioning, 2022-02-03). The step is documented as part of the release
branching process in the CMake Maintainer Guide `Help/dev/maint.rst`.
The files generatd by `install(EXPORT)` and `export()` commands
are known to work with policies as of CMake 3.22, so enable them
in sufficiently new CMake versions.
Link line construction starts with `LINK_LIBRARIES` and appends
dependencies from the transitive closure of `INTERFACE_LINK_LIBRARIES`.
Only the entries of `LINK_LIBRARIES` are considered direct link
dependencies. In some advanced use cases, particularly involving static
libraries and static plugins, usage requirements need to update the list
of direct link dependencies. This may mean adding new items, removing
existing items, or both.
Add target properties to encode these usage requirements:
* INTERFACE_LINK_LIBRARIES_DIRECT
* INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE
Fixes: #22496
Enabling `IMPORTED_NO_SYSTEM` on a target built within the project has
no effect on the build system, but it is still a useful way to set the
property on imported targets generated by `install(EXPORT)` and
`export()`.
Issue: #17364
The files generatd by `install(EXPORT)` and `export()` commands
are known to work with policies as of CMake 3.21, so enable them
in sufficiently new CMake versions.
