RFC: adding a temporary, non-BC gauranteed, 'private' library .. where?
Friedrich W. H. Kossebau
kossebau at kde.org
Thu Apr 23 21:53:57 BST 2009
Hi Aaron and all,
Mercredi, le 22 avril 2009, à 22:21, Aaron J. Seigo a écrit:
> hi all ..
> i'd like to move libknotificationareaitem somewhere that apps can get to it
> for 4.3, before looking at moving the actual class into libkdeui for 4.4.
> is there any guidance on where it could go, how it should be installed,
> etc? right now i'm thinking of putting the headers in knotificationarea/,
> but half of me wonders if a generic private/ or experimental/ include dir
> wouldn't be a bad idea ...
> any thoughts?
A general solution to this problem would be very welcome also by me.
With Okteta I have a similar problem, in that the core libraries are
interesting to developers of other programs but not stable enough to have a
guaranteed API until the rest of KDE 4 lifetime.
When I asked for that problem on the release-team list it was proposed to me
to put the libs to extragear so they are not bound to the promises made for
the ABI of the general KDE modules. I haven't yet followed that proposal for
* some extra work for me
* people running trunk might not fetch also the stuff from _extra_gear, so
Okteta would not be built which would mean less testers.
So if there e.g. can be another module for libraries, in the dependency chain
between the base lib modules (kdelibs and kdepimlibs) and the base modules
(kdebase, kdeutils, kde...) and not bound to ABI stability between major
releases, that would be helpful. To give new libraries a chance to develop.
And if adding this module or another similar option, on this change also
kdebase should be finally split up as well, by lifting the three hidden
modules on the level where they belong.
Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta
More information about the kde-core-devel