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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
