Howto fix KDE4 Buildsystem with CMake CVS

Alexander Neundorf neundorf at
Wed Feb 6 00:00:55 CET 2008

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. 
Additionally I think using LINK_DIRECTORIES() might mess with cmake library 
searching/ordering mechanisms. 

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

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


More information about the Kde-buildsystem mailing list