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
Revert commit f3ad061858 (Add usage requirements to update direct link
dependencies, 2022-01-12, v3.23.0-rc1~44^2) and the property storage
updates in its predecessor commit 193a999cd5 (cmTarget: Add
INTERFACE_LINK_LIBRARIES_DIRECT{,_EXCLUDE} backtrace storage,
2022-01-06, v3.23.0-rc1~44^2~1) from the 3.23 release branch.
After initial experience using the feature in practice, additional
design considerations have been raised for discussion in the original
issue. To avoid rushing this for the 3.23 series, we've decided to
revert the feature for now so it can be revised for a future release.
Issue: #22496
There's no benefit to storing the CPACK_PRODUCTBUILD_DOMAINS
prefix in a variable and appending to it in the C++ code. It has the
disadvantage of making it harder to find usages of the variables with
a suffix appended to that string. Expand out the strings at the places
they are used so that they are easier to spot.
* Remove unecessary logic for selecting gbuild
-- CMake defaults to the Cache entry
* Support building multiple targets
* Fix error when ctest passes in a vector potentially containing
an empty string.
-- At minimum build the ALL_BUILD project, never just the Top Project.
* Add verbose support
* There can only be one top-level project per directory because the
project() command can only be used once per directory. Multiple calls
of project() only use the last invocation.
The top level project and the target projects are all in the same
directory so they are easier to find and looks nicer in the GUI.
All of the ancillary project files are located in the target
subdirectory.
Use a Custom Target for ALL_BUILD instead of special code.
This also changes the name from <project>.ALL_BUILD.tgt to
ALL_BUILD.tgt. The name change is part of standardizing the
CMakePredefinedTargets names.
The fix in commit e4f1b301fe (cmake: Allow arbitrary args passed to
CMake script, 2020-05-04, v3.18.0-rc1~211^2) only applied to "cache"
arguments like `-DFOO`. Extend the fix to allow arbitrary arguments
that collide with other CMake arguments like `-S` and `-B`.
Since commit c1e812ad4f (target_link_libraries: Improve tolerance of
unquoted generator expressions, 2022-02-15, v3.23.0-rc2~11^2) we
accumulate consecutive non-keyword arguments to recover an unquoted
generator expression as a single entry. When given multiple consecutive
non-genex library names, the grouping breaks our logic that expects each
entry is either a raw target name or a genex. Revise the logic to only
accumulate multiple arguments when they end inside a partial genex.
This bug caused `target_link_libraries` to stop wrapping static library
private dependencies in `$<LINK_ONLY:...>` for `INTERFACE_LINK_LIBRARIES`
when multiple consecutive library names are given. Add a test case
covering that behavior.
Fixes: #23302
In commit 2f1ffa003c (find_package: Add support for default GLOBAL
imported targets, 2022-03-10) we added a field without an initializer.
This was exposed by a few failures in nightly testing. Previously it
worked only by chance that the member's memory had suitable values.
Brad King