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

Viktor Engelmann viktor.engelmann at qt.io
Fri Mar 17 10:32:57 CET 2017


On 17.03.2017 06:39, Thiago Macieira wrote:
> 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).
...
>> 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. 
>> 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.

I see some valid concerns here, but I think in practice, André is right.
We are talking about BC breakages that happen because of libstdc++ BC
breakages. If distros switch from one libstdc++ to a binary incompatible
libstdc++ *between releases*, then it's their own fault they have to
rebuild and redeliver everything. And if they don't, then qt libs don't
break BC either, so there is no problem in that case.

I think it might be wisest to allow BC breakage under the premise that
the major version number must change whenever BC is broken. That would
tell people loud and clear that they have to rebuild (also the library
names are likely to change then, so old versions of a program can't
accidentally load the binary incompatible library)

-- 

Viktor Engelmann
Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin

Viktor.Engelmann at qt.io
+49 151 26784521

http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B





More information about the Development mailing list