https://bugs.kde.org/show_bug.cgi?id=306323
--- Comment #18 from Alex Turbov <i.za...@gmail.com> --- (In reply to comment #17) > (In reply to comment #14) > > (In reply to comment #13) > > > The idea and the patch are both wrong. > > > > > > - Adding the boost include dir to kdepimlibs_include_dirs supposes that : > > > 1/ Boost was already found, > > yes it was! it was detected by root's CMakeLists.txt while compile... after > > that, if pykde for example, starts to compile on same host boost definitely > > will be here. > > You misunderstand what KdepimLibsConfig.cmake.in does: ${boost_include_dir} first of all it's not ${boost_include_dir} but @Boost_INCLUDE_DIR@. latter will be detected by root CMakeLists.txt and rendered into KdepimLibsConfig.cmake (by configure_file()) w/ actual path to /usr/include/boost_1.50 for example... so being installed any other software (like pykde) will find boost headers and everything will be allright... > is not replaced by the boost include dir. KdepimLibsConfig.cmake will > contain the exact same variable. have you tried the patch? just apply and look into generated file... it helps me to fix broken compilation of KDE SC 4.9.1 in gentoo w/ boost-1.50.0 > > When used in, say pykde, it will have no value because nothing will have > looked for boost. you'll maybe wondered, but it will... I guess someone misunderstand smth... and that is not me... > > Please note that: > - *ALL* the KDE projects' CMakeLists.txt already have an include_directories > line (for the kdelibs and Qt includes). So adding one for boost when it's > needed is not a big deal. > > - There's no reason to have a special rule for boost in kdepimlibs (we have > many 3rd party dependencies used in the project such as libical, libprison, > libprison's dependencies, kdelibs, Qt and even the akonadi server is > included) It's just because you really lucky! For example libical require NO additional #inclue paths (-I flags): zaufi@gentop /work/kdepimlibs-4.9.1 $ pkg-config --cflags --libs libical -lical -licalss -licalvcal -lpthread but if I'll install it somewhere else than default (/usr) prefix and tell to cmake to use that installation, any project which depends on kdepimlib and implicitly on libical would *FAIL* to compile (just like pykde and non "default" #include boost path) -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs