RFC: adding a temporary, non-BC gauranteed, 'private' library .. where?

[Thiago Macieira]

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

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...
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/20090423/b09512cf/attachment.sig>