[Bug 306323] [kdepimlibs] missed boost dependency in KdepimLibsConfig.cmake.in

Alex Turbov i.zaufi at gmail.com
Fri Sep 7 20:53:39 BST 2012


https://bugs.kde.org/show_bug.cgi?id=306323

--- Comment #18 from Alex Turbov <i.zaufi at 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 at . 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 at 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.



More information about the Kdepim-bugs mailing list