kwallet binary compatibility

[Ingo Klöcker]

On Friday 22 August 2008, Michael Leupold wrote:
> On Friday 22 August 2008, Michael Pyne wrote:
> > On Thursday 21 August 2008, Michael Leupold wrote:
> > > Does that mean that I have to make a kwalletbackend2 and declare
> > > the old library deprecated? (By the way, no client code will have
> > > to be changed but the one in kwalletd - unless someone decided to
> > > use libkwalletbackend directly).
> >
> > I would argue that unless it was made clear in the API that they
> > were meant to be internal that the KDE_EXPORT implies they are
> > public.
>
> True. I think the backend is basically just excluded from doxygen to
> not make anyone else but kwalletd use it. But still someone else
> might have done that.
>
> > In addition if applications linking against kwallet linked against
> > that class (it's exported after all) then maintaining binary
> > compatibility would mean that you can't break that class even if we
> > do declare it as internal later.
> > These are just my thoughts but I would run nm on like
> > kwalletmanager or something and see if your classes are listed in
> > there.
>
> As far as I saw everything is exported - so I'll have to go ahead and
> create a second backend.

Are the header files installed? (Looking at the CMakeLists.txt I don't 
see anything that would install the header files explicitly.)

If the header files are not installed then you should be on the safe 
side.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080823/4be09274/attachment.sig>