cmake CMP0028 & missing targets - what does one do about it?

[Harald Sitter]

alohas

While investigating a wall of build failures in the kubuntu ci this
morning I stumbled upon a very interesting problem.

Problem tldr: target A links library B, A doesn't get the includes of
link libraries of B by default. e.g. A links B, B links karchive, A
doesn't have access to the karchive headers. also if karchive wasn't
found in a super-scope of A and B, A will not know about karchive.

Ultimately the build failures are fallout from the public dependency
tightening, they do however hightlight a bit of a problem with how we
handle find_packages outside the main cmakelists as well as linking to
targets from within the same cmake project. I feel like I had seen a
solution for that somewhere so excuse my stupidity in case we already
have a well understood solution to this apparently not so uncommon
problem.

The two repos I noticed the problem with is muon [1] and kio [2].

The general problem is that they build a library that links against
some framework (in case of muon it's KF5::KDELibs4Support, in case of
KIO it's KIOFileWidgets linking against KF5::XmlGui). Both repos have
somewhat split find_package calls that happen as close to the import
target use as possible, giving the import targets a lower scope than
main cmakelists.
In both repos another target (in muon it's another lib, in KIO a test
case) then links against the respectively library that linked the
framework.
This is where things go terribly wrong.

Since the find_package calls are in a lower scope, the target linking
the lib target does not know about them. This ideally results in a
cmake warning about CMP0028 and a colon target that cannot be resolved
(which KIO ignores by forcing old policy behavior, weeh).

Now the obvious way to resolve this is to find_package in both scopes,
such that the targets become available.

BUT...

that would duplicate logic and is altogether not going to scale very well.

SO...

Question 1: can we somehow pass along imported target information to
linkees within the same cmake project? Much like we do with the
generated cmake configs that will import the interface dependencies.

Question 2: If there is such a way, is that preferred over duplicated
find_packages?

Question 3: Should we really force the old policy behavior regarding
CMP0028 considering it might very well cause a build failure which
then doesn't have an obvious cause anymore? (KIO autotests dir does
that right now)

I pushed a minimal example of the problem as I understand it to [3].
Problem is in a/CMakeLists.txt

[1] https://launchpadlibrarian.net/200634395/buildlog_ubuntu-vivid-i386.muon_4%3A5.2.1%2Bgit20150319.1139%2B15.04-0ubuntu0_BUILDING.txt.gz
[2] https://launchpadlibrarian.net/200604917/buildlog_ubuntu-vivid-amd64.kio_5.8.0%2Bgit20150319.0312%2B15.04-0ubuntu0_BUILDING.txt.gz
[3] kde:scratch/sitter/CMP0028