https://bugs.kde.org/show_bug.cgi?id=306323
--- Comment #22 from Alex Turbov <[email protected]> --- (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@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@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@gentop /work/kdepimlibs-4.9.1 $ grep --color=always -nr --include=*.{h,hh,hpp} "Boost_VERSION" * zaufi@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. _______________________________________________ Kdepim-bugs mailing list [email protected] https://mail.kde.org/mailman/listinfo/kdepim-bugs
