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

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 20 de marzo de 2017 12:11:17 -03 Thiago Macieira wrote:
> Em segunda-feira, 20 de março de 2017, às 11:53:50 PDT, Lisandro Damián
> 
> Nicanor Pérez Meyer escreveu:
> > In the (2) case it will mean that we distro packagers will be forced to
> > change Qt's SONAME. Yeah, the whole of it.
> 
> Why? We're not changing our ABI. To be clear: we're not proposing replacing
> what we have right now with std::function, but adding it to new places as
> the needs arise.
> 
> 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.

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.

Yes, on Debian we do really rely on the SONAME for this (+/- tricks, but that 
gets ugly).

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

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.

We do track symbols for each version+build+arch we do. We never found an ABI 
break on Qt, we do really hope to keep things like that, or have an appropiate 
method to deal with the situation.

> Tell me of other libraries that follow this
> naming scheme, because I haven't heard of them.

The last time maintainers for other libs had to rename them "by hand" to do 
the proper transition, thus provinding stuff like libfoo5a instead of libfoo5. 
If I remember correctly boost was one of them. Yes, this is doable, but means 
we end up with a different naming scheme than uptream.

Now if having distros with different SONAMEs for the same source code is 
acceptable (ie, it doesn't gets coordinated from the Qt project itself) then I 
see no reason to let this happen, after all the C++ ABI doesn't changes often.

> But note I want to limit which API we're allowed to expose.

I know, and I'm really grateful for that.

> > So if we are going to only expose libstdc++'s API weshould really consider
> > making it part of the SONAME. After all we discussed some time ago that
> > the
> > libstdc++ lib doesn't breaks BC so frequently.
> 
> No, we shouldn't because it's the frigging C++ *Standard* *Library.* EVERY
> single C++ application links to it, if you as much as used "new" in your
> code.
> 
> I've said this before: there's a way to split libstdc++ into two, so that
> the library providing the base functionality (new/delete, typeinfo,
> std::exception, cxxabi) is not the same library as the one providing the
> higher-level functionality. That would allow sharing the base things that
> all C++ applications and libraries need from the higher level classes,
> including that of other implementations like libc++.
> 
> Yet no Linux distribution does that. For 4 years many have provided libc++
> without opting to this solution. That tells me they are not interested in
> providing binary compatibility between libstdc++ and other C++ standard
> library implementations. As a consequence, if they are not, why should we
> be?

That's beyond me, as I never digged into it's maintainance.

-- 
You know you're brilliant, but maybe you'd like to understand what
you did 2 weeks from now.
  Linus Benedict Torvalds.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170323/d020bf29/attachment.sig>