[Development] Notes on QtCore session @ QCS2016

[Thiago Macieira]

Em terça-feira, 6 de setembro de 2016, às 07:24:19 PDT, Marc Mutz escreveu:
> On Tuesday 06 September 2016 02:02:50 Thiago Macieira wrote:
> > > https://codereview.qt-project.org/#/c/142782/
> > 
> > We decided to make a QUIP out of this, in a later session. Stay tuned.
> 
> ENOABBREV

It's a backronym, so expanding doesn't help. You need to read Louai's full 
post, when he posts it.

> Instead, since some indeterminable (to me) time in the not too distant past,
> an entirely *arbitrary* selection of options is now _included_ in the BC
> guarantee, incl. the one of std library implementation, but most notably
> *not* release/debug on Windows, even though that would be just as possible,
> and more desireable (there are no two std impls for MSVC). It is being
> argued that this is a compatibility that was provided by Qt versions
> before, but that's a smoke screen: a) If you never used the types in the
> API, it's trivial to make that particular guarantee and b) it falls apart
> as soon as a user is using Qt API (which exists!) that uses std types,
> making it all just theoretical.

I agree with you that we shouldn't need to specify our binary compatibility in 
terms of other libraries. Like you said, we don't do it for the MSVC runtime, 
like we don't for libpng (12 or 16?) , libjpeg (8, 62 or turbo?), 
libmysqlclient or libudev.

It was a *choice* not to depend on the C++ Standard Library ABI  for features 
outside of the language support. The choice was made during Qt 5.0 
development, in response to the -no-stl option being removed. It was 
originally done so that applications and libraries on Apple platforms could 
choose to use libstdc++ or libc++: it was common back in 2012 that 
applications would need to link to proprietary libraries that used libstdc++ 
and could not easily be recompiled. That choice extended to GCC 4.9 & 5.0 that 
broke compatibility, and it turned out to be a bonus for us because Qt-only 
applications did not need to be recompiled.

> IMO it plain *isn't* Qt jobs to provide the user with that compatibility.
> That's the job of the *compiler vendors*.

Agreed. But it's a nice bonus. 

> It feels like the BC leak is allowed to leak just enough to use the std
> implementation incompatibilities as an excuse to keep std types out of the
> Qt ABI when equally desireable compiler options, foremost debug/release,
> are not included in the guarantee.
> 
> That's an arbitrary distinction and Qt should stop trying to provide more
> compatibility than the compiler vendors themselves are willing to give.

We could choose that route too. The QCS recommendation is that we revisit 
this, again, next year.

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