[Development] Use of std::function in Qt API
André Pönitz
apoenitz at t-online.de
Fri Mar 17 00:26:20 CET 2017
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), nor, in case the distro did it
nevertheless, do I understand why a user would need to upgrade packages in that
case, nor, in case the distro *and* the user consciously decided to upgrade, why
that would be a problem.
> 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?
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?
> 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.
Andre'
More information about the Development
mailing list