kdeexamples buildsystem

[Alexander Neundorf]

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
> > > > > 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
> > 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