RFC v2: adding a temporary, non-BC gauranteed, 'private' library
Aaron J. Seigo
aseigo at kde.org
Fri Apr 24 18:08:48 BST 2009
On Friday 24 April 2009, Modestas Vainius wrote:
> On 2009 m. April 23 d., Thursday 23:50:46 Aaron J. Seigo wrote:
> > svn location: extragear/libs/knotificationitem
> > headers: $INCLUDE_PATH/knotificationaitem-1/
> > lib name: $LIB_PATH/libknotificationitem-1.so
> > namespace: Experimental::
> > release of tarball done prior to kde 4.3.
> > will most likely be removed post-4.3 and rolled into kdelibs. if not,
> > changes will results in a s,-1,-2,g to the above and another release.
> > objections?
> Why do you insist on creating shared libraries?
because it's simple, easy and i don't have to recompile all N apps just to
test changes properly.
think about the system tray here: we've ported half a dozen or so apps
scattered all over kde's svn. when i make a change in the lib, right now i
just restart those apps.
with the static lib mentality, i now have to go and relink each app first.
just as bad, when introducing changes in the lib, person A may get different
behavior from person B even if they both have the same svn rev just because
one or the other didn't relink that app.
a shared lib is simpler and more respecting of my time as a developer.
> If ABI is unstable, create
> static libraries instead (or at least make it an option). Static libraries
> will ensure that:
> 1) use of the library is not widespread. It is experimental after all.
static libs guarantee no such thing.
> 2) developers do not have to deal with sonames, abi and other versioning
> nonsense when there is no intention to keep ABI stable
cmake deals with it for us; it's not a big deal. it's one more word in the
> (your goal should be
> to develop a stable API/ABI, not to keep library experimental forever).
> it's bad from security support POV, but if 1) is met, it may be more
> acceptable than suffering from constant ABI brekages.
if the API is going through constant ABI breakage, then it isn't ready for
this process. only when an API is ready for trialing for actual inclusion in,
say, kdelibs would you put it in there. that means a fairly confident API, but
not confident enough to commit to 5+ years of support.
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Qt Software
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel