[Development] Use of std::function in Qt API

[Edward Welbourne]

Earlier, Thiago said:
>>> The point however is that if libstdc++ does break its ABI, then
>>> you'll have to rebuild half the world anyway. The few libraries and
>>> applications that did use Qt and were not affected would be the
>>> minority. Telling them apart could be a higher cost than just
>>> rebuilding -- remember, ALL C++ code links to libstdc++, regardless
>>> of whether it was subject to the ABI break or not.
>>>
>>> And if libstdc++ changes its soname, then you HAVE to rebuild Qt and
>>> everything, anyway.
On quinta-feira, 23 de março de 2017 12:13:09 PDT Lisandro Damián Nicanor
Pérez Meyer wrote:
>> Right, but without a proper SONAME change we can not track what needs
>> to get rebuilt and what doesn't (because it already was), what can
>> migrate from unstable to testing, what binary is compatible with
>> another and so on.

Let me just check I've understood this one correctly: you need the
SONAME change as soon as we introduce any stl type in our API because,
regardless of it being new API, during the lifetime of that version of
Qt, there may be changes to the stl ABI, that would break Qt.  So the
existing Qt SONAME needs to express the stl ABI version so that, after
the update, things built before pick up the old Qt while things built
after pick up the new.  Did I understand that correctly ?

I'm a little unclear on why that can't be changed with the first stl ABI
break; but I guess having Qt's build infrastructure (which hasn't
changed) express the stl ABI version (which has) in its SONAME would
mean you *only* have to rebuild, without also hacking Qt's build
infrastructure to modify the SONAME - which is why different distros
would end up with different SONAMEs, because each hacks that its own
way.

So, once Qt contains any stl in its ABI, it would be courteous to
distros to incorporate the stl ABI version in the Qt SONAME, so that any
stl ABI break requires *only* a recompile of Qt and any other packages
directly affected by the stl ABI break, rather than propagating to all
packages.  I'm a little unclear on why that won't still be all packages;
can you elaborate ?

Thiago Macieira (23 March 2017 20:50)
> Understood, but that's not Qt's problem. If libc or libstdc++ cause a
> BC break, it's their responsibility to update the SONAME. If they
> don't, you (Debian) get to complain to them.

If my guess above is near the mark, an update to stl's SONAME won't help
us here.  Qt's SONAME would also need to change when stl's ABI breaks.

> Either way, the benefit of keeping Qt immune to those breaks is so
> small to the point that it's not worth it.

As long as stl ABI breaks are rare, yes.
The tricky part is that everyone makes mistakes ...

>>> > Oh, and if some non-other Qt api is exposed it should also become
>>> > part of the SONAME.
>>>
>>> Again, why? We've exposed C and Xlib API for years and have never
>>> had "X11" in the name (or "xcb" now).

My understanding was that the only exposure we give to that is passing
an opaque handle through, from the library to our client.  As long as
the client is only ever using it to pass back to the same library,
without looking inside the black box - and as long as the opaque type
hasn't changed (void* was the example ISTR) - this isn't really an ABI
dependency.  The issue would arise if we, or the client, were to look
inside that opaque type, possibly by calling some inline of the library;
but I doubt this happens for the types involved.  They come from the X
or xcb library and travel back to it; any given run-time process only
deals with one version of that library, so all's well.  That would even
imply a need to link Qt against the library, of course; so I suspect my
understanding is incomplete ... how *are* we using X/xcb types ?

>> Maybe because they never broke? At least in the time I've been
>> maintaining Qt in Debian we have never encountered an issue with
>> this. This is from the last Qt 4 releases before Qt5.
> 
> Right and that's the entire point: there are some libraries (a
> whitelist) whose types we'll have in our public ABI, so Qt's ABI is
> then dependent on theirs. We'll only add libraries that have a good
> track record of keeping BC.

Surely Qt's API can use any library-derived type that's opaque (void*,
most obviously, via whatever typedefs), as long as the library has no
inlines that unwrap it.  That means the client's only possible use of it
is to pass it back to the same library we got it from, with no risk of
incompatibility.

	Eddy (not an expert on shared libraries).