Armadillo is typically built as a wrapper library, which is what this
find module has historically supported, but it does not have to be.
If not, then instead of armadillo itself, we need to link to some
combination of dependencies and not armadillo.
85ad7190f3 curl: Set build options the way we need for CMake
d61c3bd505 Merge branch 'upstream-curl' into update-curl
735ea3001a curl 2020-03-04 (b8d13668)
84dc14a967 curl: Update script to get curl 7.69.0
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4429
In commit f5126badd8 (add_custom_command: convert DEPENDS path arguments
to absolute paths, 2019-12-18, v3.17.0-rc1~263^2) we updated the
documentation to describe the behavior introduced by that commit.
However, the behavior was removed again by commit fd0ba705ce
(add_custom_command: check if a relative path should be an in-source
path, 2020-01-09, v3.17.0-rc1~141^2~4) without updating the
documentation.
Update the documentation again to describe the behavior as of the latter
commit. Spell out the steps that `cmLocalGenerator::GetRealDependency`
and `cmTargetTraceDependencies::IsUtility` use to add file-level and
target-level dependencies.
Much like AIX, IBM i (OS identifier "OS400") implicitly adds `extern
"C"` around system header files included with the `-isystem` option.
Update the condition added by commit c688b401d3 (cmstd: Modernize CMake
system headers, 2019-08-04, v3.16.0-rc1~81^2~1) to treat `IBM i` as we
do AIX.
a833aa1167 Fix dependencies on targets linked through object libraries
3b3de0fd17 Tests: Extend ObjectLibrary test with case for object lib dependencies
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4427
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
Add the test case from commit bab24e782c (target_link_libraries:
Propagate dependencies of object libraries, 2018-12-10,
v3.14.0-rc1~260^2) to the main ObjectLibrary test.
