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

[Alex Turbov]

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

--- Comment #22 from Alex Turbov <i.zaufi at gmail.com> ---
(In reply to comment #21)
> you have to choose your answer at some point:
> 
> - either you use ${Boost_INCLUDE_DIR}, then the path is not hardcoded but
> you must find boost before kdepimlibs,
where did you see I use ${Boost_INCLUDE_DIR}??? That is just your imagination
(caused by misunderstanding)

> - or you use @Boost_INCLUDE_DIR@ and in that case the path is hardcoded in
> KdepimLibsConfig.cmake

damn, can you just look into installed KdepimLibsConfig.cmake:

zaufi at gentop /work/kdepimlibs-4.9.1 $ cat
/usr/lib64/cmake/KdepimLibs/KdepimLibsConfig.cmake | grep
KDEPIMLIBS_INCLUDE_DIRS
set(KDEPIMLIBS_INCLUDE_DIRS        "/usr/include" "/usr/include/KDE"
"/usr/include/boost-1_50")

Do you see all that "hadrcoded" paths!!?  I'm going to tell you a bad news:  IT
IS THAT SUPPOSED TO BE!
There are paths to explicit dependency of kdepimlibs exactly that it was when
this package gets compiled on my system. And that paths MUST be hardcoded (this
file called *redistributable config file*, remember?) because it if you are
going to redetect smth here you may find a *different* version of boost or even
KDE... and application (stil that unfortunate pykde, will may fail again, but
this time because kdepimlibs was compiled w/ different boost version) -- IT IS
WHY ALL REDISTRIBUTABLE CONFIGURATION FILES IN THE *WORLD* MUST HAVE
"HARDCODED" PATHS TO THEIR DEPENDENCIES!! (for examples explore any *.pc file
from /usr/lib/pkgconfig/, if you still do not believe me...)

And AGAIN: it is *incorrect* to use `set()` here! Build system should use
`set_and_check()` as claimed by cmake manual (do you able to read the manual?)
And AGAIN: the manual told NOT to use `configure_file()` to produce a
redistributable package config!

 zaufi at gentop /work/kdepimlibs-4.9.1 $ grep --color=always -nir
"KdepimLibsConfig.cmake" *
CMakeLists.txt:7:############### The kdepimlibs version (used e.g. in
KdepimLibsConfig.cmake) ###############
CMakeLists.txt:216:# now create the KdepimLibsConfig.cmake file, which will be
loaded by
CMakeLists.txt:231:# all the following variables are put into
KdepimLibsConfig.cmake, so
>>>> THIS LINE INCORRECT <<<<
CMakeLists.txt:264:configure_file(KdepimLibsConfig.cmake.in
"${CMAKE_CURRENT_BINARY_DIR}/KdepimLibsConfig.cmake" @ONLY)
CMakeLists.txt:280:             
${CMAKE_CURRENT_BINARY_DIR}/KdepimLibsConfig.cmake

> None of these solution is acceptable. 
> In both case we would still need a find_package(Boost) in the modules using
> kdepimlibs anyway (because we need Boost_FOUND, Boost_VERSION).

yes, I learned how to grep sources a long time ago:

zaufi at gentop /work/kdepimlibs-4.9.1 $ grep --color=always -nr
--include=*.{h,hh,hpp} "Boost_VERSION" *
zaufi at gentop /work/kdepimlibs-4.9.1 $ grep --color=always -nr
--include=*.{h,hh,hpp} "Boost_FOUND" *

There is no entries in any public header files (more over in any C/C++ source
file of kdepimlibs) -- it is only cmake-time variable...
(even if kdepimlibs C++ sources would use Boost_VERSION it must be rendered as
-D flag into KdepimLibsConfig.cmake... just for notice...
now forget this and continue reading)

and back to find_package() -- KdepimLibsConfig.cmake NEVER SHOULD USE IT! Now,
I hope you know WHY...
(correct, because there is a change to find smth other than kdepimlibs was
compiled/linked with!)

> 
> If Gentoo is the only distribution having a problem with the KDE
> buildsystem,  it's the Gentoo buildsystem that needs some fixes. (and maybe
> pyKDE that needs a trivial fix)

Just tell me: why packages which DO NOT USE boost explicitly MUST detect it???

-- 
You are receiving this mail because:
You are the assignee for the bug.