changes to how kdepimlibs and kdebase/workspace are installed and found
neundorf at kde.org
Thu Dec 18 19:43:44 CET 2008
On Thursday 18 December 2008, Maciej Mrozowski wrote:
> On Tuesday 09 of December 2008 01:42:14 Alexander Neundorf wrote:
> 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
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.
P.S. nice that you come up with this here on the list :-)
More information about the Kde-buildsystem