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

[Alexander Neundorf]

Hi,

On Thursday 18 December 2008, Maciej Mrozowski wrote:
> On Tuesday 09 of December 2008 01:42:14 Alexander Neundorf wrote:
> [...]
>
> Hi
>
> I have some questions related to mentioned changes in KDE4 build system.
> Introducing these methods will surely make it possible to keep CMake
> modules easier to maintain in the future as it should even effectively
> eliminate the need of FindXXX.cmake files for cmake-controlled libraries.
> And while this change is very good in general and I'm all for it -
> explicitly merging all workspace libraries in one logical unit
> (KDE4Workspace) effectively killed our automatic package building facility
> in Gentoo - the one that relies on splitting packages at
> library/application level. (so far it affects only some additional
> kdeartwork/kdetoys modules, but it's supposed to eventually spread
> everywhere I guess).
> The problem is - all workspace library targets (those with EXPORT in
> 'install') need to be built *together* to generate fully-functional
> KDE4WorkspaceConfig.cmake. The only workaround for us - Gentoo KDE
> maintainers would be to hack build system to get rid of this mechanism
> unfortunately. Hence following questions:
> - what policies are in question, when some library in kdebase-workspace is
> promoted to/removed from 'KDE4Workspace" unit? 

Right now it's every library installed from kdeworkspace which also installs 
headers, i.e. which is supposed to be used by others.

> The question really is
> about, is it supposed to be added there just when needed and how often such
> changes are going to happen?

I guess not too often, but we don't have policies about how fast and how many 
things may be added.

> - is it considered to split KDE4Workspace logical unit in just per
> library/package basis? 

Not that I know of.

> So that for example libplasmaclock would build and 
> install its own cmake module, libkworkspace its own, etc. 

Of course it is always nice tro have it as modular as possible (while keeping 
it nice and clean to read). So if there are some easy things to do to make 
your work easier I'd happily accept patches.

> It would still 
> preserve it's main functionality (out-of-the-box library finding) and it
> would at least allow us (and maybe some other distribution packagers) to
> build KDE4 packages without thoroughly hacking build system.

I understand the issue.
To have a KDE4WorkspaceConfig.cmake, you need to install it completely. YOu 
don't want to do it but instead do it separately.
I think the correct solution would be to have separate FindKScreenSaver.cmake, 
FindKPlasmaSomething.cmake etc. files, and they could be installed 
additionally and used to the complete FindKDE4Workspace.cmake.
So, IMO this would be correct and clean, but at the same time also some 
additional work.
You could also use a modified (old-style) FindKDE4Workspace.cmake file, which 
does find_library() for all the different libs, and then you would have these 
libs set whioch have been actually found.

I'm not sure what a good solution is.
I would understand if you would say you wan to install e.g. libkhtml 
separately, for kdeworkspace I'm not sure it makes that much sense. I mean, 
it's just a few small libraries.

Alex

P.S. nice that you come up with this here on the list :-)