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

[Maciej Mrozowski]

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 
IMPORTED_LINK_DEPENDENT_LIBRARIES_RELEASE in example)?
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/' 
CMakeLists.txt

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.

-- 
regards
MM


----------------------------------------------------------------------
Wyslij internetowa kartke z zyczeniami!
Kliknij >>> http://link.interia.pl/f1ff2