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

[Thiago Macieira]

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.

> 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). Tell me of other libraries that follow this naming 
scheme, because I haven't heard of them.

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

> 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?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center