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

Maciej Mrozowski reavertm at poczta.fm
Thu Dec 18 00:45:35 CET 2008


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? The question really is about, 
is it supposed to be added there just when needed and how often such changes 
are going to happen?
- is it considered to split KDE4Workspace logical unit in just per 
library/package basis? So that for example libplasmaclock would build and 
install its own cmake module, libkworkspace its own, etc. 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.

It it's not considered, how we could handle this problem properly? (provided 
merging KDE4 workspace libraries is the least attractive option as creating 
those logical units may spread to other KDE components in a future, like for 
kdenetwork etc)

-- 
regards
MM

----------------------------------------------------------------------
A moze lepiej wziac prysznic we dwojke - oszczedzaj wode!
http://video.interia.pl/obejrzyj,film,104059



More information about the Kde-buildsystem mailing list