On Thu, Mar 19, 2015 at 2:16 PM, Harald Sitter <sit...@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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
