kdeexamples buildsystem

Michael Jansen kde at michael-jansen.biz
Wed Aug 10 12:24:55 UTC 2011

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 git at git.kde.org: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
> 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 

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.

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.

This kind of setup is only for experts anyway. Or we just do it and therefor 
push distros to at least support it for our - many - packages.



> Alex
Michael Jansen

More information about the Kde-buildsystem mailing list