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

[Thiago Macieira]

Em quinta-feira, 16 de março de 2017, às 16:26:20 PDT, André Pönitz escreveu:
> On Thu, Mar 16, 2017 at 01:23:55PM -0400, Matthew Woehlke wrote:
> > On 2017-03-14 13:33, André Pönitz wrote:
> > > In general, I am not overly sold on ABI compatibility promises. I
> > > personally could live without and find SC of more practical value. The
> > > most important "feature" of ABI compatibility guarantee for me is that
> > > it limits people from doing overly excessive source-incompatible
> > > changes.
> > 
> > Distros are likely to care; a Qt BC break requires a mass rebuild of
> > everything that uses Qt (which translates into lots of users needing to
> > update lots of packages when Qt changes).
> 
> I am three steps away from understanding what you are saying:
> 
> I don't get why a library (Qt or anything else) BC break would cause a
> distro to update packages outside their usual upgrade cycle (when most, or
> rather all, of the packages will be recompiled anyway)

Your paretheses is incorrect: not all distros recompile everything at every 
release. Since libraries keep BC, what has been once compiled can be kept; 
only what changed needs to be compiled again.

Rebuilding the world is an expensive proposition.

> , nor, in case the
> distro did it nevertheless, do I understand why a user would need to
> upgrade packages in that case,

Ever heard of bug fixes? That's why users upgrade packages.

> nor, in case the distro *and* the user
> consciously decided to upgrade, why that would be a problem.

Because if there's a BC break, then all the packages linking to that library 
would need to be upgraded, all at the same time. If every library did this, at 
uncontrolled points in their releases, every single bugfix would require 
building everything that changed downstream from it and thus downloading it 
all and installing. 

There's also the issue of what happens during that upgrade process, when 
certain programs will be already running linking to the old library, and may 
suddenly load plugins that were compiled against the new ABI, causing crashes 
left and right if you've installed updates until you reboot.

And there are also binaries that don't come from distributions. When dealing 
with developers, it happens often that people have stuff lying around they 
build a couple of months ago. BC breaks are a recipe for unexpected and hard-
to-debug issues. The libstdc++ break showed how developers aren't aware of 
this issue and keep running into problems. I saw several times people 
reporting build errors that included "unresolved symbol <something with 
std::__cxx11>". And that was a minor break.

> > Distros may refuse to update Qt within a distro release as a result, which
> > means users are stuck with older Qt for longer.
> 
> Yes, and, so what?

It would be less of a problem if we actually released bugfix releases. We 
don't. Case in point: 5.8.1.

So, no, going from 5.7.1 to 5.8.0 to 5.9.0 to get bugfixes is not acceptable, 
especially if that implies recompiling half the distro and forcing reboots.

> We are not talking about security problems. What is wrong with running a
> half-year, or worst case maybe even a two year old version of some library
> as base for the bulk of the applications?

Because there are worse than or equally bad issues as security problems. For 
example, during 5.4, all Qt-based applications would crash when I plugged in 
my external monitor. Without a bugfix, it would mean being unable to *work*.

It's bad enough that our policy is "no bugfix for youf or 6 months". It would 
be worse if it were "and when you get those bugfixes, you need to rebuild 
everything or download a gigabyte of new builds".

> > All that more or less already applies to the standard library however
> > (probably most distros don't accept a standard library BC break without a
> > mass rebuild anyway), so Qt insulating against BC breaks in the standard
> > library is maybe less necessary.
> 
> That was the starting point here. Not Qt breaking BC by itself, but allowing
> C++ BC breakages to affect otherwise "pure Qt" applications.

Distros did shield from rebuilding after the libstdc++ breakages. But I am 
with others now saying that we shouldn't have to go out or our way to do that. 
If libstdc++ does it, it's for a good reason.

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