Previously we always used content guarded by `$<LINK_ONLY:...>`
in `LINK_LIBRARIES`, even when evaluating for non-linking usage
requirements. Add a policy to honor `LINK_ONLY` in `LINK_LIBRARIES`
the same way we already do in `INTERFACE_LINK_LIBRARIES`.
Similar to GNU tar add a --touch option to the tar extract command to
skip extracting the timestamps from the files in the archive
effectively touching them as if they were just created.
Issue: #22746
Remove the requirement that the variable name have a prefix while
keeping the suffix requirement. Require that the property name
contains an underscore. Update docs and tests accordingly.
Fixes: #23340
In commit f3ad061858 (Add usage requirements to update direct link
dependencies, 2022-01-12, v3.23.0-rc1~44^2), we evaluated the transitive
closure of `INTERFACE_LINK_LIBRARIES` as a non-linking usage requirement.
That left out `INTERFACE_LINK_LIBRARIES_DIRECT` link dependencies that
appear behind private dependencies of a static library, guarded by the
`$<LINK_ONLY:...>` generator expression. At the time, that decision was
intentional, in order to prevent arbitrary usage requirements from
leaking out of `PRIVATE` dependencies.
Since then, we've revised evaluation of `LINK_LIBRARIES` to distinguish
between collecting link dependencies and other usage requirements. Use
that information when following `INTERFACE_LINK_LIBRARIES` to collect
the matching kind of requirements from `INTERFACE_LINK_LIBRARIES_DIRECT`.
Fixes: #22496
We evaluate `LINK_LIBRARIES` and `INTERFACE_LINK_LIBRARIES` for two purposes:
* Constructing the link line.
* Collecting usage requirements.
We evaluate `INTERFACE_LINK_LIBRARIES` separately for each purpose in
order to support the `$<LINK_ONLY:...>` generator expression used to
express private link dependencies of a static library. Previously we
only evaluated `LINK_LIBRARIES` for linking, and used that result for
collecting usage requirements too. Therefore `$<LINK_ONLY:...>` does
not work in `LINK_LIBRARIES`.
With the introduction of `INTERFACE_LINK_LIBRARIES_DIRECT`, evaluation
of `LINK_LIBRARIES` now needs to distinguish these two cases in order to
honor link dependencies encountered through `$<LINK_ONLY:...>` without
also exposing other usage requirements through private dependencies of a
static library. Revise internal infrastructure to distinguish the two
cases when evaluating `LINK_LIBRARIES`. Make the information available
in code paths for `INTERFACE_LINK_LIBRARIES_DIRECT` and `LINK_ONLY`.
Defer actually using the information to later commits.
Issue: #22496
Use the "ours" merge strategy because we only want to revert the change
from the 3.23 branch, not from `master`. It will be revised for
inclusion in a future release series.
Manually remove the 3.23 release note that would have been removed by
this merge without the "ours" strategy.
97f4aa1f05 ci: Add OpenJDK to Debian and Fedora base images
78d0613695 ci: Drop p4 binary checksum because the download URL is not stable
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7102
8468dfb35f FindMatlab: Use -batch option in matlab_add_unit_test if possible
ebb0685824 FindMatlab: Add fallback to use -batch option in version extraction
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7088
78e0204e81 Help: Clarify when add_test and test properties support generator expressions
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7101
78e0204e81 Help: Clarify when add_test and test properties support generator expressions
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7101
Silvio