RFC: adding a temporary, non-BC gauranteed, 'private' library .. where?
thiago at kde.org
Thu Apr 23 19:54:50 BST 2009
Aaron J. Seigo wrote:
>> And like QXmlStreamXXXX classes today, you can't forward-declare them.
>even in application code?
Correct. The QXmlStreamXXXX classes are now a mess. They are technically a
source- and binary-compatibility break on Mac (32-bit). But it works just
fine if you #include <qxmlstream.h> and you don't offer API in a library
containing those classes.
Anyways, here's what I suggest: a simple bundle of .cpp and .h files.
Anyone who wants to use this copies into their projects (svn:externals or,
if we were using Git, git-submodule).
Using kdesupport (external project) won't work here because of the kdelibs
The other option I see is a new "/trunk/kdetemporary" module that inserts
itself in the dependency chain between kdelibs and kdebase (same level as
kdepimlibs). This module would be managed as kdesupport: i.e., no
"kdetemporary" release, but a release of each inner component. Which means
someone must produce tarballs, so that in a few years' time, if someone
wants to build KDE 4.3, they know where to find the dependency.
But with this module, it's possible to create shared libraries: as long as
the soname changes for every BC-breaking release.
I don't like this precedent.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- 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