[Kde-pim] Source incompatible change :(

[Kevin Krammer]

On Saturday, 2011-12-10, David Faure wrote:
> On Friday 09 December 2011 22:29:46 Kevin Krammer wrote:
> > On Friday, 2011-12-09, David Faure wrote:
> > > On Friday 09 December 2011 19:00:34 =?ISO-8859-1?Q?S=E9rgio?= Martins
> 
> wrote:
> > > > Hi,
> > > > 
> > > > Commit  2eb3de21a61b4816770ae9bdd38b07d799b60337 in kdepimlibs seems
> > > > to be ABI and source incompatible.
> 
> Actually, I don't think it is. I didn't have to recompile kmail after
> making the change. Unless the app code puts the StatisticsProxyModel *
> into a QSFPM *, the change doesn't break SC. And it doesn't break BC
> either, because the vtable is the same (QAIM virtual methods).

The FAQ [1] on techbase says
"You cannot, for existing classes, change the class hierachy in any way"

> > > Aww, crap, why do we have ABI requirements for libs that are only used
> > > by kdepim?
> > 
> > There is no way of telling if something is only used by kdepim if it is
> > not in kdepim.
> > In this particual case it is part of libakonadi-kde which is almost
> > certainly used in other places.
> 
> This proxy is for showing unread mails in the folder tree. "Almost
> certainly" there are other mail clients based on libakonadi-kde?

I would have assume that an incompatible change requires new so-name, thus 
effecting all application linking the library.

> > > So, should I revert and keep kmail slow for theoretical 3rd-party apps,
> > > or is there a good reason for the BIC/SIC requirements?
> > 
> > Same as for kdelibs, i.e. part of the platform.
> > We keep libs for which we don't want or can't keep strict compatibility
> > requirements inside the same module as the app.
> 
> I wonder why StatisticsProxyModel is in kdepimlibs then, all its users are
> in kdepim. I think putting everything into a public lib "by default" is
> shooting ourselves in the foot, in the long run.

Not all users might have been in kdepim at the time of introduction, e.g. 
Mailody might have used it as well.

> See, this is different in kdelibs, we only put there stuff that is used by
> multiple kde modules/apps.
> 
> In kdepimlibs, I have the feeling that everything akonadi-related was put
> into libakonadi-kde, just because it was easiest at the time, without
> realizing that this was going to make future changes harder.

No, we have plenty of kdepim only libs, including Akonadi ones, in kdepim.
We like the ability to change stuff when necessary, so we only move classes 
into kdepimlibs when necessary.

Cheers,
Kevin

[1] http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++

-- 
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: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20111210/bc2dc876/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/