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

[Aleix Pol]

On Thu, Mar 19, 2015 at 2:16 PM, Harald Sitter <sitter at kde.org> wrote:
> 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.
I'd say the only thing that makes sense is to have globally defined
find_packages(). Simplifies the whole issue.

>
> Question 2: If there is such a way, is that preferred over duplicated
> find_packages?
As soon as it's the dependencies of the dependencies, I'd say it
doesn't make sense to duplicate.

>
> 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)
We want the new behavior, IMHO.

>
> 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

Aleix