RFC v2: adding a temporary, non-BC gauranteed, 'private' library

[Kevin Krammer]

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 
development package.
At least I don't build all the dependencies from source when building KDE from 
trunk.

> Where it was
> 	kdesupport->kdelibs->kdepimlibs->kdebase->kdeutils
> it would become
> 	kdesupport->kdelibs->knotificationitem->kdepimlibs->kdebase->oktetalibs->
> kdeutils
> and perhaps worse, if more developers take chance of giving their libs some
> publish feedback before freezing the API.

No, in both cases
kdelibs->kdepimlibs->module.

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?

Potentially

> 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.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090424/cc68636c/attachment.sig>