Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`, now with "east const" enforcement.
Use `clang-format` version 18.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
Issue: #26123
Since commit 1e49880472 (cmGeneratorTarget: Avoid boolean trap in usage
requirement lookup, 2021-12-08, v3.23.0-rc1~245^2) we have clarified
the distinction between compile-only and link-only usage requirements.
Rename the `LinkInterfaceFor` enum to `UseTo` to clarify that its role
is to specify the purpose of usage requirements.
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
Linkers always use object files explicitly specified on the command line
regardless of where they appear. Move them to the front of the list of
linked libraries in so that symbols required by the object files can be
resolved by any library.
Issue: #22149
Add an `OPTIMIZE_DEPENDENCIES` target property and supporting
`CMAKE_OPTIMIZE_DEPENDENCIES` variable to optionally enable pruning and
flattening of outgoing dependencies from static libraries. Since they
do not actually link, they only depend on side effects of their
dependencies. Therefore we can drop dependencies that contribute no
side effects.
bd0d03386b cmComputeComponentGraph: Move work out of constructor into Compute() method
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5079
The computation of Tarjan's algorithm is an expensive operation which
should not be done in the constructor. Move this work into a dedicated
Compute() method, and call this method explicitly.
When an object library is used via `target_link_libraries`, any targets
listed in the object library's `INTERFACE_LINK_LIBRARIES` closure should
become direct dependencies of the consuming target. However, these were
accidentally left out by `cmComputeTargetDepends::CollectTargetDepends`
because object libraries are encountered through external object sources
first and then added to the `emitted` set which blocks them from being
processed as link dependencies.
This was not noticed by the test case in commit bab24e782c
(target_link_libraries: Propagate dependencies of object libraries,
2018-12-10, v3.14.0-rc1~260^2) because the relevant dependency appears
transitively through the object library target itself.
Re-order the logic to process link dependencies first, and then external
object sources. That way object libraries used via
`target_link_libraries` will be treated as such by dependency analysis.
This also adds missing backtrace information for object libraries used
via `target_link_libraries`. The missing information was mentioned in a
FIXME comment in the RunCMake.FileAPI test added by commit ea0a060168
(fileapi: Add test for codemodel v2, 2018-11-09, v3.14.0-rc1~257^2~7).
That comment itself was dropped by commit a0de350e2f (FileAPI test:
Break gen_check_targets() into JSON files, 2020-02-07), but we can now
update the corresponding location in the `.json` files to have the
now-expected backtrace information.
Fixes: #20421
Set the MinTypeNameLength option to an impossibly high value in order
to limit the diagnostics to iterators. Leave new expressions and cast
expressions for later.
Suppress some cases in `Source/cmGeneratorExpressionNode.cxx` and
`Source/cmUVHandlePtr.h` where a few older compilers require a
user-defined default constructor (with `{}`).
Carry a backtrace on every link item, not just link implementation
items. For now the non-impl items will still have empty backtraces at
runtime, but this will allow us to introduce values over time.
If two imported targets in different directories have the same name we
should still be able to propagate transitive link dependencies from
both. Fix the target and link dependency analyzers to de-duplicate
targets using target pointers rather than target names since the
pointers will not be duplicated even if the names are.
Issue: #18345
Avoid exposing the item name implicitly as std::string. When the item
is a target, avoid storing a second copy of its name.
Most link item construction is paired with calls to `FindTargetToLink`
to get the possible target pointer. Rename these methods to
`ResolveLinkItem` and refactor them to construct the entire item.
Note: This only allows `OBJECT` libraries to be on the right-hand side
of `target_link_libraries` but still does not link its object-files to
the target on the left-hand side.
Issue: #14778
Add an index to Change cmLocalGenerator::GeneratorTargets for faster lookup by
name.
Also changed a bunch of uses of cmLocalGenerator::GetGeneratorTargets() to take
const references instead of copying the vector.
Represent generator targets as a map (name -> target) to make name lookups more
efficient instead of looping through the entire vector to find the desired one.
