RFC v2: adding a temporary, non-BC gauranteed, 'private' library
kevin.krammer at gmx.at
Fri Apr 24 20:16:28 BST 2009
On Friday, 2009-04-24, Friedrich W. H. Kossebau wrote:
> > It is just another external library, i.e. it is either optional for
> > additional features or required, in which case it needs a CMake check for
> > the required version.
> Sure. But see this from a KDE developers point of view: It increases the
> complexity of the whole build process. Where one was used to think in
> modules without needing to care much what is contained, one now also has to
> always think of the individual packages which are linked into the
> dependency chain and always need to be up-to-date.
As with any other external library I would just install the respective
At least I don't build all the dependencies from source when building KDE from
> Where it was
> it would become
> and perhaps worse, if more developers take chance of giving their libs some
> publish feedback before freezing the API.
No, in both cases
You would only need to inject knotificationitem if for whatever reason you
want to build an not-yet-released version.
Very similar to how you'd do it if you want Phonon from kdesupport/trunk
rather than using the one in Qt.
> > > Or kdepimlibs
> > > (who perhaps might be happy to have some more time to make the
> > > akonadi-based APIs stable)?
> > We do that in module private libs in kdepim.
> Private as in? Are the libs used outside of kdepimlibs?
They are in kdepim, so yes outside of kdepimlibs.
> Are headers installed whose API changes incompatible for 4.x+1?
> Would kdepim 4.3 compile against kdepimlibs 4.4, or rather, would kdepim
> 4.3 compiled against kdepimlibs 4.3 run with kdepimlibs 4.4?
Sure. KDE does have an API and ABI stability policy and kdepimlibs is part of
the KDE development platform.
> Then I just guessed these published parts of kdepimlibs are still candidate
> for changes, so it might have been a bad example :)
Public API can and will only be changed in a compatible way.
That's why we have the private libs.
> > If they are specific to a certain version of Okteta, just release them
> > with that version, no?
> But as far as I was told once they are released and published with
> kdeutils, I have to ensure ABI-stability until KDE5. Or? Or do you mean
> release them from extragear?
Well, if you define the stability guarantee for your libs that way, then you
should probably stick to it.
I just thought you might not follow the stricter rules for platform libraries.
Usually application level APIs are far less stable.
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel