changes to how kdepimlibs and kdebase/workspace are installed and found

Maciej Mrozowski reavertm at
Fri Dec 19 21:41:49 CET 2008

On Friday 19 of December 2008 19:40:43 Brad King wrote:

> Oops, in my proposal I didn't realize the libraries were interdependent.
>     For some reason I was thinking they were all separate modules
> sharing a namespace.  Currently there is no way to do this unless the
> builds are separated too (where each library exports itself for import
> by its dependents).  The design of the automatic export file generation
> and installation was greatly simplified by enforcing the dependencies
> instead of having some mechanism for interdependent exports.  I
> currently have no plans to support inter-dependent exports but it could
> be done in the future.

Actually I wouldn't really propose inter-dependent exports. It's not necessary 
as KDE guys don't need it as they usually build whole workspace, and in Gentoo 
we already handle inter-dependencies at package level (and we use workspace-
toplevel CMakeLists.txt so all required libraries are being found, we just 
comment out not necessary add_subdirectory from build). I believe other 
packagers do it similar way.
That being said, if anything - we would really only need a way to export those 
workspace libraries just as they are - without dependency information (so far 
attached error message occurs).

> Here are some other ideas:
> 1.) Write the export files by hand since they are for packages that
> always install to a specific location and always provide the same thing.
>   This is not very maintainable though.
> 2.) Post-process the export file to divide up the import rules.  I
> cannot guarantee the exact layout of these files will remain the same in
> future CMake versions though.

"Write by hand" and "post-process" means probably some amount of serious 
work/rework - not acceptable here :)

> 3.) Hack the export file to put if(EXISTS) around each import rule to
> check that the imported file exists.  Perhaps in the future CMake could
> generate this automatically.  I didn't consider it since the import rule
> is put in an export file that gets installed along with the target.  In
> your case you have a packaging mechanism that splits the install tree up
> with more granularity than CMake knows.

Hmm, I don't understand the purpose .. to always install (somehow) those 
exports and make them find libraries they 'represent'? Don't we have 
FindXXX.cmake already for that purpose?

> 4.) Keep the single export file but teach KDE4WorkspaceConfig.cmake to
> detect by some other means (existence of a mark file that comes with
> each package) whether each target is really available.  Then set boolean
> variables or properties on the imported targets to indicate availability.

Yeah, but that seems to be against of the goal to introduce out-of-the-box 
library finding/importing.

Is there any way of forcing install (TARGETS EXPORT) or install (EXPORT) 
without dependency information or make it possible to manually add 
dependencies (those that are going to appear in 
If this considered workaround, then you can easily skip the idea as we can 
workaround this problem with simple
sed -i -e 's/${KDE4WORKSPACE_KSCREENSAVER_LIBRARY}/kscreensaver/' 

I just wanted to throw some proposition to be considered in a future. and I 
would personally prefer robust solutions rather than workarounds/hacks in KDE4 
or in any CMake-controlled build systems.


Wyslij internetowa kartke z zyczeniami!
Kliknij >>>

More information about the Kde-buildsystem mailing list