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

[Alexander Neundorf]

On Thursday 18 December 2008, Alexander Neundorf wrote:
> 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.

Did you follow the discussion on kde-core-devel ?
http://lists.kde.org/?t=122993563900001&r=1&w=2

The conclusion was basically that we (KDE) recommend not to split workspace 
into separate packages.

Workspace exports the following libraries:

taskmanager
kworkspace
solidcontrolifaces
solidcontrol
processui
lsofui
plasmaclock
nepomukqueryclient
nepomukquery
kscreensaver   
weather_ion
kwineffects
kdecorations
ksgrd
kephal

Having each of them as a separate package really doesn't make a lot of sense. 
Can you come up with a split into maybe 3 or 4 packages which make sense 
(i.e. a plasma one, a nepomuk one, etc.) ?

Alex