It is Ok (w/ cmake FindBoost module) to have the boost library installed somewhere else than 'default' /usr/include/boost. Nowadays in gentoo this is /usr/include/boost_1.50 (it is where the root 'boost' foder located). Unfortunately kdepimlibs loose this (important) dependency and provide KdepimLibsConfig.cmake w/o it! So other packages, which are uses it, will got implicit dependency from boost, but unable to compile well cuz #include paths (got from installed KdepimLibsConfig.cmake) just incomplete! an attached patch will fix it. Reproducible: Always Steps to Reproduce: 1. install boost somewhere else 2. make sure there is no /usr/include/boost 3. compile and install kdepimlibs 4. try to compile smth that use kdepimlibs Actual Results: compile errors when some kdepimlibs headers are used (w/ boost #includes) Expected Results: compile w/o errors PS: unfortunately bug tracker UI force me to choose some component... so I randomly select kdepimutils... but defenitely this is build system related bug...
Created attachment 73694 [details] add missed boost dependency, so other packages could be compiled well
We need to have your compile error. And will not add a boost in *Config* And in all kdepim we have: include_directories( ${Boost_INCLUDE_DIR} ) so it's not problem "compile errors when some kdepimlibs headers are used (w/ boost #includes)" which program ?
(In reply to comment #2) > We need to have your compile error. > And will not add a boost in *Config* > And in all kdepim we have: > include_directories( ${Boost_INCLUDE_DIR} ) > so it's not problem > > "compile errors when some kdepimlibs headers are used (w/ boost #includes)" > which program ? first I've found is pykde. I've discovered this problem while building fresh KDE 4.9.1 from portage. the patch attached allow me to finish this compilation...
Fix pyKDE and not kdepimlibs or report it to pyKDE As I told you we added ${Boost_INCLUDE_DIR} in kdepim when necessary => add it in pyKDE Regards
(In reply to comment #4) > Fix pyKDE and not kdepimlibs > or report it to pyKDE > > As I told you we added ${Boost_INCLUDE_DIR} in kdepim when necessary > => add it in pyKDE maybe it would be better to look into sources before telling... --- zaufi@gentop /work/kdepimlibs-4.9.1 $ cat CMakeLists.txt | head -n 69 | tail -n 6 set(Boost_MINIMUM_VERSION "1.34.0") if (WIN32) find_package(Boost ${Boost_MINIMUM_VERSION}) # (jstaniek) temp. fix unless we have graph library, not just headers else() find_package(Boost ${Boost_MINIMUM_VERSION} COMPONENTS graph) endif() --- as u may c boost would be checkd ALWAYS. Lets check the header files where boost headers are included: zaufi@gentop /work/kdepimlibs-4.9.1 $ grep -nr --include=*.h "#include <boost" * | wc -l 63 zaufi@gentop /work/kdepimlibs-4.9.1 $ grep -r --include=*.h "#include <boost" * | sed 's,.*#include <\(.*\)>,\1,' | sort | uniq boost/bind.hpp boost/enable_shared_from_this.hpp boost/mpl/eval_if.hpp boost/mpl/identity.hpp boost/optional.hpp boost/scoped_ptr.hpp boost/shared_ptr.hpp boost/static_assert.hpp boost/type_traits/is_pointer.hpp boost/type_traits/is_same.hpp boost/type_traits/remove_pointer.hpp boost/utility/enable_if.hpp boost/variant.hpp boost/weak_ptr.hpp --- so u r trying to tell me that I have to report to undefined number of OTHER applications which r use kdepimlibs to fix their kdepimlibs detection scripts for IMPLICIT dependency on boost??? ARE YOUR SERIOUS/CRAZY!? It is ONLY kdepimlibs dependency!!! And it is EXPLICIT! kdepimlibs MUST provide a (self-sufficient) configuration file which, being used, allows to ANY other appication to detect EVERYTHING that require to successfull compilation/linking w/ kdepimlibs! If I use kdepimlibs in my application I want to detec ONLY kdepimlibs... I dont care about everything this library depends on!! Following your "logic" other applcations have to check for kdelibs, qt4, x11 libs & etc when they just wants to use kdepimlibs!!!! its completely INCORECT! wbr PS: google for library design best practices
kdepimlibs config is for kdepimlibs not for adding boost. => I will reclose it.
Who is the address of RESOLVED UPSTREAM?
Laurent, you might need to ask on the build system mailing list to be sure, but from what I can see, the dependency is indeed missing, because public kdepim headers reference boost headers.
There's nothing to ask. Adding the boost include dir is totally wrong.
Using a correct resolution
(In reply to comment #10) > Using a correct resolution Where is the bug id for pykde?
You have an explicit dependency on Boost, and this means you should also detect and provide the required include directories. Even if an external application does not use *any* boost functions itself it will fail using kdepimlibs. So, the external application does *not* depend on boost, but kdepimlibs does. Resolving as invalid is not productive.
The idea and the patch are both wrong. - Adding the boost include dir to kdepimlibs_include_dirs supposes that : 1/ Boost was already found, 2/ All of kdepimlibs needs boost These two statements are incorrect. Adding a find_package(boost) is excluded because of 2 and the posted patch is wrong because of 1. And even without 1 & 2, that would mean we'd have to support FindBoost.cmake which supposes that you have a high confidence in the boost SC (and in that case, you're also terribly wrong). Oh and I won't mention the boost attempt to provide a BoostConfig.cmake which is in no way compatible with FindBoost.cmake...
(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. If we are talking about binary distros (like debian/rh) it is job of distromaker to add an interpackage dependency kdepimlibs-dev on boost-dev. btw, the way a *redistributable configuration file* generated in kdepimlibs is incorrect!! It is invalid to use `set()`! Use `set_and_check() instead to make sure desired paths really exists! (read details in cmake's manual about CMakePackageConfigHelpers module) > 2/ All of kdepimlibs needs boost yes, they are! according root CMakeLists.txt boost detected and set to include_directories *unconditionally* -- so ALL kdepimlibs use boost! > > These two statements are incorrect. Adding a find_package(boost) is excluded NO IT DOESN'T! Check CMakeLists.txt in the source root...
> - Adding the boost include dir to kdepimlibs_include_dirs supposes that : > 1/ Boost was already found, From /CMakeLists.txt: set(Boost_MINIMUM_VERSION "1.34.0") if (WIN32) find_package(Boost ${Boost_MINIMUM_VERSION}) # (jstaniek) temp. fix unless we have graph library, not just headers else() find_package(Boost ${Boost_MINIMUM_VERSION} COMPONENTS graph) endif() macro_log_feature(Boost_FOUND "Boost C++ Libraries" "Required by core components" "http://www.boost.org" TRUE "${Boost_MINIMUM_VERSION}" "Boost must include the boost-graph library") [...] include_directories (${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR} ${KDE4_INCLUDES} ${Boost_INCLUDE_DIR}) OK, it's not marked as REQUIRED. Which means build takes place as well if it is not found. However: > 2/ All of kdepimlibs needs boost > > These two statements are incorrect. Adding a find_package(boost) is excluded > because of 2 and the posted patch is wrong because of 1. The find_package(boost) is already there, see above. And please have a look at the following output: huettel@grenadine ~/tmp/kdepimlibs-4.9.1 $ find . -name CMakeLists.txt -exec grep -i boost {} + ./kblog/CMakeLists.txt:include_directories(${Boost_INCLUDE_DIR}) ./kioslave/imap4/CMakeLists.txt:include_directories(${imap4_optional_includes} ${Boost_INCLUDE_DIR}) ./syndication/tests/CMakeLists.txt:include_directories( ../ ${Boost_INCLUDE_DIR} ) ./syndication/CMakeLists.txt:include_directories( ${Boost_INCLUDE_DIR} ) ./CMakeLists.txt:set(Boost_MINIMUM_VERSION "1.34.0") ./CMakeLists.txt: find_package(Boost ${Boost_MINIMUM_VERSION}) # (jstaniek) temp. fix unless we have graph library, not just headers ./CMakeLists.txt: find_package(Boost ${Boost_MINIMUM_VERSION} COMPONENTS graph) ./CMakeLists.txt:macro_log_feature(Boost_FOUND "Boost C++ Libraries" "Required by core components" "http://www.boost.org" TRUE "${Boost_MINIMUM_VERSION}" "Boost must include the boost-graph library") ./CMakeLists.txt:include_directories (${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR} ${KDE4_INCLUDES} ${Boost_INCLUDE_DIR}) ./gpgme++/CMakeLists.txt:include_directories( ${GPGME_INCLUDES} ${Boost_INCLUDE_DIR} ) ./gpgme++/CMakeLists.txt:set( GPGMEPP_INCLUDE ${INCLUDE_INSTALL_DIR} ${GPGME_INCLUDES} ${Boost_INCLUDE_DIR} ) ./mailtransport/CMakeLists.txt: ${Boost_INCLUDE_DIR} ./akonadi/tests/testrunner/CMakeLists.txt: ${Boost_INCLUDE_DIR} ./akonadi/tests/etm_test_app/CMakeLists.txt: ${Boost_INCLUDE_DIR} ./akonadi/tests/CMakeLists.txt: ${Boost_INCLUDE_DIR} ./akonadi/tests/benchmarker/CMakeLists.txt: ${Boost_INCLUDE_DIR} ./akonadi/CMakeLists.txt: ${Boost_INCLUDE_DIR} ./akonadi/kmime/CMakeLists.txt: ${Boost_INCLUDE_DIR} ./akonadi/contact/CMakeLists.txt: ${Boost_INCLUDE_DIR} ./includes/tests/CMakeLists.txt: ${Boost_INCLUDE_DIR} ./kimap/tests/CMakeLists.txt:include_directories( ${CMAKE_SOURCE_DIR}/kimap ${Boost_INCLUDE_DIR}) ./kimap/CMakeLists.txt:include_directories( ${CMAKE_SOURCE_DIR}/kioslave ${SASL2_INCLUDE_DIR} ${Boost_INCLUDE_DIR} ) ./kldap/CMakeLists.txt: ${Boost_INCLUDE_DIR} ./qgpgme/tests/CMakeLists.txt:include_directories( ${Boost_INCLUDE_DIR} ) ./qgpgme/CMakeLists.txt: include_directories( ${GPGME_INCLUDES} ${CMAKE_SOURCE_DIR}/gpgme++ ${Boost_INCLUDE_DIR} ) This means kblog, kioslave/imap4, syndication, gpgme++, mailtransport, akonadi, kimap, kldap, and qgpgme already use Boost includes in the CMakeLists.txt, which makes me strongly doubt if they build without Boost. Is kdepimlibs useful if you switch off these components? (Not that it is done anywhere in the build system.) > And even without 1 & 2, that would mean we'd have to support FindBoost.cmake You already do.
(In reply to comment #15) > > OK, it's not marked as REQUIRED. Which means build takes place as well if it > is not found. I'm in real doublt about this! > > 2/ All of kdepimlibs needs boost > > > > These two statements are incorrect. Adding a find_package(boost) is excluded > > because of 2 and the posted patch is wrong because of 1. > > The find_package(boost) is already there, see above. > > And please have a look at the following output: > huettel@grenadine ~/tmp/kdepimlibs-4.9.1 $ find . -name CMakeLists.txt -exec > grep -i boost {} + [skipped] > ./CMakeLists.txt:include_directories (${CMAKE_SOURCE_DIR} > ${CMAKE_BINARY_DIR} ${KDE4_INCLUDES} ${Boost_INCLUDE_DIR}) [skipped] everything below this line (from the sources root CMakeLists.txt) doesn't matter (just *redundand* appending another one instance of Boost_INCLUDE_DIR)
(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} is not replaced by the boost include dir. KdepimLibsConfig.cmake will contain the exact same variable. When used in, say pykde, it will have no value because nothing will have looked for boost. You'll get a similar result with this test CMakeLists.txt: project(test) message(STATUS "boost_include_dir: ${boost_include_dir}") result: the variable is empty because nothing will define it. 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)
(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)
(In reply to comment #18) > > 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... Thanks, hardcoding the path is yet another reason why this patch will not be accepted
(In reply to comment #19) > (In reply to comment #18) > > > 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... > > Thanks, hardcoding the path is yet another reason why this patch will not be > accepted OMG! Where did you see hardcoded path?
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, - or you use @Boost_INCLUDE_DIR@ and in that case the path is hardcoded in 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). 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)
(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???
(In reply to comment #21) > 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) Here is another thought for you to think about: suppose the following sequence of packages install... 0) install boost-1.49 1) compile and install kdepimlibs 2) (maybe after some time) install boost-1.51 3) trying to install pykde (or whatever other package depends on kdepimlib) so finally we have: 0) 2 versions of boost installed (yeah, it is Ok) 1) one kdepimlib linked w/ one of boost 2) unfortunate pykde which is (folliwing your "logic") trying to detect a correct version of boost (which was used whan kdepimlibs gets compiled) now try to solve this puzzle good luck!
Created attachment 73730 [details] Test patch "/usr/include/boost-1_50" *is* a hardcoded path for a 3rd party library. that makes a huge difference which you keep on ignoring: KdepimLibsConfig.cmake is the configuration file for kdepimlibs, not for anything else. (that's exactly what Laurent stated) Anyway, the bug report is now closed and so is this useless discussion (In reply to comment #11) > (In reply to comment #10) > > Using a correct resolution > > Where is the bug id for pykde? @Johannes, please test the attached patch in pykde (applies on current master)
(In reply to comment #24) > Created attachment 73730 [details] > Test patch > > "/usr/include/boost-1_50" *is* a hardcoded path for a 3rd party library. > that makes a huge difference which you keep on ignoring: Completely opposite! You are trying to state that detecting kdepimlibs' third party dependencies is not a problem of kdepimlibs, but that packages, who so dare to use kdepimlibs! How do you suppose they could do that? (takein in account that there could be few versions of boost, libical, whatever installed simultaneously) and yes, "hadrcoding" explicit dependencies (YES, ALL DEPENDENCIES EVEN THIRD PARTY) is the purpose of *redistributable config files*! > KdepimLibsConfig.cmake is the configuration file for kdepimlibs, not for > anything else. (that's exactly what Laurent stated) ORLY!? KdepimLibsConfig.cmake DO NOT USED IN A KDEPIMLIBS CODE AT ALL!!! It's just generated by root's CMakeLists.txt and installed into target prefix!!! -- open your eyes finally! (use grep, can you?) It required for complicated scheme of KDE cmake files, so other packages may use `find_package(kdepimlibs)` and get all required variabled defined... > Anyway, the bug report is now closed and so is this useless discussion so? reopen required?
(In reply to comment #22) > 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?) Oh and for the record: the KDE4 build system must work with CMake 2.6.4. I suppose you'll realize how silly this parenthesis is, after reading the doc again, right ?
(In reply to comment #26) > > Oh and for the record: the KDE4 build system must work with CMake 2.6.4. I That is only means that generation of KdepimLibsConfig.cmake must be refactored (i.e. reinvented a wheel) or it is time to upgrade cmake requirement...
Please refrain from reopening this report
(In reply to comment #28) > Please refrain from reopening this report You still don't realize that the problem couldn't be "solved" by hacking pykde CMakeLists.txt???? It is configuration problem of kdepimlibs and noone else!
the three possible solutions are: a) fix boost header location in Gentoo (which is what Christophe wants us to do). Since Gentoo still wants to support multiple concurrent Boost installations, and since FindBoost.cmake actually finds everything correctly, this is not going to happen. b) add a FindBoost call to the CMakeLists.txt file of *every* kde app that uses kdepimlibs (this is how Christophe wants to work around the problem for kde sc apps, see comment 24) c) add the one-line patch to kdepimlibs build system that records and re-exports boost include location for the boost that kdepimlibs was compiled against. On the whole this bug is a neat example how people dont read or dont bother to think through what others write, and resort to nitpicking instead. Since we're unwilling to patch every single application using kdepimlibs, we'll probably end up applying Alex's patch locally.
b is already what is done in all the KDE modules. This bug report became noisy for pointless reasons. A constructive report would have been: pykde4 fails to build because of the following error: ... Your choice anyway, It won't be the first time we get reports caused by the gentoo toy and the decisions made by its maintainers