kdepimlibs uses boost header-only libs but doesn't provides this #include dependency in it's KdepimLibsConfig.cmake after install, so other applications (like pykde) fail to compile (w/ boost-1.50) because they detect only kdepimlibs and do not detect boost in their CMakeLists.txt (and it is quite Ok! why to detect smth if you don't use it directly??) Reproducible: Always Steps to Reproduce: 1. make sure you have >=boost-1.50-r2 installed 2. make sure there is no /usr/include/boost 3. just try to emerge KDE 4.9.1 Actual Results: pykde failed to compile because of kdepimlibs. which doesn't provides an implicit depedency on boost in it's KdepimLibsConfig.cmake (which is used to detect kdepimlibs by others) rejected upstream bug report https://bugs.kde.org/show_bug.cgi?id=306323&list_id=197338
Created attachment 323096 [details, diff] patch to add missed implicit dependency
When i understand upstream right this is a duplicate of bug #434044 ?
(In reply to comment #2) > When i understand upstream right this is a duplicate of bug #434044 ? not a duplicate but blocks.
But upstream says that this approach is totally wrong and should be fixed in pykde...
(In reply to comment #4) > But upstream says that this approach is totally wrong and should be fixed in > pykde... Ok, I'll try to be polite (but it's really hard)... Just ask any SANE developer: what he expect from `find_package(...)` in cmake, or running `pkg-config --cflags ...`, or autoconf macros authors... should that configuration tools return a *COMPLETE* compiler options needed for successful compilation of his project which is depend on smth? Or is it Ok to call a bunch of other detectors to find depecdencies of its dependecy?? pykde DO NOT use boost explicitly! so WHY pykde developers should detect it??? I've got a broad experience as maintainer of closed and open source project based on autotools(+pkg-config) and cmake, and first time in my life met such a stupid case... just suppose if I wrote a library with a bunch of dependencies (boost, poco, qt4, kdelibs, lot of others), but in redistributable configuration file (.pc, .m4 or .cmake) just provide only -I/prefix/of/mylibrary and -lmylib... so my users HAVE to (re)detect all that IMPLICIT dependencies by themself... I guess than mylib will have the only user (me) in that case... or it must be really *brilliant*, so users will use it and write a sane configuration tool for me, but I'll reject the patches! (as KDE upstream now do)... damn stupid!
(In reply to comment #4) > But upstream says that this approach is totally wrong and should be fixed in > pykde... try to ask upstream for reasons of that stupid behaviour... why they want to force OTHERS (pykde devs maybe some other projects) to do their job...
Patch added in 4.9.1-r1 and later. Thanks. Upstream is not really behaving constructive.
*** Bug 434044 has been marked as a duplicate of this bug. ***
