Howto fix KDE4 Buildsystem with CMake CVS

Andreas Pakulat apaku at gmx.de
Wed Feb 6 00:15:11 CET 2008


On 06.02.08 00:00:55, Alexander Neundorf wrote:
> On Tuesday 05 February 2008, Andreas Pakulat wrote:
> > On 05.02.08 23:41:43, Alexander Neundorf wrote:
> ...
> > > No, we shouldn't add LINK_DIRECTORIES() somewhere global. We would do it
> > > only for KDE4_LIB_DIR, but the same breakage can happen with just any
> > > other library in any other dir.
> >
> > So you want to add that to the top level CMakeLists.txt in each module?
> 
> No, this shouldn't be used at all.
> Because as I said, the same problem can not only happen for libraries which 
> are incidentially in KDE4_LIB_DIR, but also for any other libraries in any 
> other directories. 

Obviously, however as far as I understood with CMake 2.6 thats simply a
bug in the buildsystem of that library/app.

> Additionally I think using LINK_DIRECTORIES() might mess with cmake library 
> searching/ordering mechanisms. 

Uhm, well, according to Brad its the right thing to do, i.e. if you want
to use -lsolid (which we seem to want, or else we'd have to hardcode the
XXX_LIBS variables instead of using cmake for this) then you have to set
the link directory for this via LINK_DIRECTORIES.

> > (I've got patches at hand for what I have of trunk/) I'm using the
> > top-level CMakeLists.txt as thats also the place where most if not all
> > modules put the INCLUDE_DIRECTORIES(${KDE4_INCLUDE_DIR}) call.
> >
> > > Maybe we need to put that compatibility switch into KDE4Defaults.cmake or
> > > something like this.
> >
> > But isn't that global as well, i.e. inside a CMake module that gets
> > automatically loaded when you do find_package(KDE4)? 
> 
> Yes, but this would make it work for all directories, not only for 
> KDE4_LIB_DIR.

Which other directories? There's no other link dir than KDE4_LIB_DIR,
except if you have extra libs in other modules used in yet another
module. So for example FindKDEPimLibs.cmake should export
KDE4_PIMLIBS_LIB_DIR or similar and all apps that want to link against
pimlibs need to do an link_directories(...).

Either that (and doing the same for KDE4_LIB_DIR, i.e. setting it in
each svn module's CMakeLists.txt) or putting the link_directories(
KDE4_PIMLIBS_LIB_DIR) into FindKDEPimLibs.cmake (and similarly for
KDE4_LIB_DIR).

> Additionally KDE4Defaults is not loaded automatically when you do 
> find_package(KDE4), it is loaded explicitely using include(KDE4Defaults), so 
> if somebody doesn't want these defaults he can simply skip using that file.

Ah, ok.

> > At least thats what I meant with "global", put it into one of the files that
> > get read as soon as you search for KDE4.
> 
> I'll try to get a better picture of that problem, so we can come up with a 
> good solution for KDE (I had to catch up with over a week of emails...)

No hurry, I've got the fixes locally so far and can continue to use
cmake cvs (as its soooo much faster for installing).

Andreas

-- 
You are taking yourself far too seriously.


More information about the Kde-buildsystem mailing list