On Wednesday 10 August 2011, Michael Jansen wrote: > On Wednesday, August 03, 2011 09:00:44 PM Alexander Neundorf wrote: > > On Tuesday 19 July 2011, Michael Jansen wrote: > > > On Friday 15 July 2011 21:37:03 Alexander Neundorf wrote: > > > > Hi, > > > > > > > > On Friday 15 July 2011, Michael Jansen wrote: > > > > > Hi > > > > > > > > > > I pushed a small project to > > > > > [email protected]:scratch/mjansen/cmake_test . That should be > > > > > git://anongit.kde.org/scratch/mjansen/cmake_test for you to clone > > > > > (in a while after anongit catches up). > > > > > > > > > > It contains 2 projects. A small helloworld lib and a binary using > > > > > it. In the toplevel is a makefile that builds the projects in > > > > > different configurations and shows what works and what not works. > > > > > Have a look inside. > > > > > > > > > > The case that now works is building the lib in 32bit and trying to > > > > > compile it in 64bit (At least here in OpenSuSE). The find_library > > > > > call accepts the 32bit lib and naturally the linking fails later. > > > > > > > > please try whether it improves the situation for you if the > > > > buildsystem example in kdeexamples uses the attached file instead of > > > > as it is currently in git. > > > > It additionally compares the 32/64bit of the installed version with > > > > the currently 32/64bitness of the currently searching project, and > > > > succeeds only if it matches. > > > > > > That naturally will fix the problem (i have not yet really tried) but > > > it still leaves the initial problem about cmake. It is very poorly > > > designed in regards to multiarch systems. > > > > Do you already have an idea how to handle multiarch in a nice way with > > LIB_SUFFIX ? > > Requiring that people set it to "64" is kindof ok. Can we also expect > > that they know they should set it e.g. "/x86_64-linux-gnu" ? > > Or we could install to "lib${LIB_SUFFIX}/${CMAKE_LIBRARY_ARCHITECTURE}" > > ... > > I always considered this part the easy to solve part. The bigger problem > with cmake was that you couldn't get it to look for libraries and config > modules in those arch paths apart from getting lucky and all the find > modules you need use pkgconfig . For all the others (config modules and > find_library calls without pkgconfig hints) there was no chance for cmake > to find the libs. > > But it looks like cmake 2.8.5 solves this problem by introducing > CMAKE_LIBRARY_ARCHITECURE. Quite a happenstance. With the same version > introducing GNUInstallDirs.cmake two of my biggest concerns about cmake are > solved in one version. heja. > > Btw. i am not that happy with the setting of the lib dir in > GNUInstallDirs.cmake. I don't think that heuristic works. What about lib32 > ?!?!.
Don't know, I wasn't involved in the GNUInstallDirs.cmake and the lib-arch stuff is not exactly the area where I'm an expert in. Please bring this up on the cmake list, or enter it in the cmake bug tracker at http://public.kitware.com/Bug > If we now could make the find_package config mode not go overboard when > reporting it could not find a config module and printing out 13 lines for > each of those probably optional dependencies and scaring the heck out of > my users i think i would organize a party. Well, it tries to explain what failed. Do you have a suggestions how to make this shorter ? > So now that this problem seems to be resolved i think it is possible to > just install into lib${LIB_SUFFIX}/${CMAKE_LIBRARY_ARCHITECTURE} if the > user selects that by a option(). That option should be off by default > because most distros don't do it and the user has to add to ld.so.conf or > set LD_LIBRARY_PATH to make it work. Do you mean that on systems with multiarch the multiarch dirs are not in the default search path ? On not-multiarch systems CMAKE_LIBRARY_ARCHITECTURE is empty. Alex _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
