[Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Kevin Kofler]

André Pönitz wrote:
> I also said that packagers (i.e. people like you) *are* affected, but I
> claimed the way they are affected is not fundamentally different from
> what happens if the packages in question uses any other library that
> doesn't guarantee BC, or - in case they have similar BC promises like Qt
> - what happens when there are jumps in major versions.

The problem is that Qt is a very widely used library, and that it is also
used by many libraries used by other libraries used by other libraries, all
of which also use Qt directly (e.g. KF5-*). The "all of which also use Qt
directly" part is how this differs from something like libpng which is
usually only used through higher-level APIs. Most applications do not link
directly to libpng. (In fact, we do this:
http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtbase.git/tree/qt5-qtbase.spec#n562
to avoid Qt applications needlessly linking directly to libpng etc. We
cannot do this with Qt because its APIs are used both directly and
transitively.)

>> If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt
>> lib break ABI we need to get Qt rebuilt and *everything* building
>> against it.
> 
> I understand that.
> 
> What I do not understand is how rebuilding an application can be
> considered a significant burden while running a full test cycle (Qt
> doesn't guarantee behavioural compatibility between versions, any
> versions for that matter) is not.

It is not *an* application. It is *many* libraries and applications.

> I fear that the answer is something along the lines of "we
> might run a smoke test, but no more", isn't it?

Well yes, testing is what our users do daily. What we need to take care of
is to not have broken dependencies (or worse, symbol lookup failures at
runtime because the ABI was changed without a soname bump). Otherwise, the
application will not run at all.

>> That's the worth nightmare we distro maintainers can dream
>> on. And yes, we would need to adjust Qt's SONAME on each change.
> 
> That's maybe one per year. With a typical distro running, say, two
> bigger updates per year replacing most packages anyway, that would
> ill-affect a distro user... how?

In Fedora, the issues this would cause are twofold:

1. In Rawhide, we would have to rebuild all packages using Qt, which are
   dozens, each time such a thing happens. But, due to the transitive
   dependency issue I mentioned at the beginning, they would have to be
   rebuilt in reverse dependency order. So we would first have to compute
   that. Our tools do not do it for us. The mass rebuilds Fedora release
   engineering does for some releases are always done in alphabetical order.
   That will not work if so many libraries have broken dependencies.

2. In Fedora, Qt is often updated to a newer version in a release, as an
   official update. And even when not, the newer version is typically
   offered in a Copr repository (a Fedora "PPA"). That would not be
   reasonably doable anymore if the new version were not binary-compatible.
   As in Debian's case, the packages (ab)using private APIs are already
   enough of an issue for us as it stands. But at least we have a list of
   those, and their interdependencies are limited, whereas rebuilding ALL
   packages using Qt would be orders of magnitude larger and not suitable
   for an update nor (realistically) even a Copr at all.

Major versions of Qt (i.e., 3, 4, 5, …) are the right place to change the
ABI, because there, we just make both versions coexist, and the transition
becomes relatively smooth. But also breaking binary compatibility in the
minor releases would not really scale.

> I am not here trying to make your life harder. I do understand that you
> would be on the receiving end in case Qt BC guarantees are lowered. I
> believe I understand the effort packagers invest, and the benefit this
> has for the Qt ecosystem. But the BC guarantee comes at quite some
> price like the inability to fix certain mistakes that slipped into some
> x.0 release, or to use certain features that only became usable a some
> x.5 time, and this price is payed both by developers and end users.

But if our users were to be stuck at, say, Qt 5.8 because 5.9 would be
binary-incompatible, they would be losing much more features.

> This is not a zero-sum game, there's room for total improvement, and
> since BC is not the only thing packagers care for a loss of BC could
> possibly get compensated by something dev can influence. At the very
> least I see no reason to forbid thinking about it.

You can always think about it, but if you do so, you will quickly find that
it is not practical at all.


Marco Bubke wrote:
> I strongly agree with Andre'. And is a BC break in the time of flat pack
> that bad? As an user I really looking forward to flat pack,  so I can
> update my heavily used Applications and being not dependent on
> distribution. This package could be much better optimize with LTO and
> profile guided optimization. Maybe sharing everything is not that smart
> anymore.

How does Flatpak solve the issue? Qt is not a leaf package. You cannot offer
a Qt Flatpak, none of the applications using Qt would get the improvements
from such a Qt. You would have to Flatpak each and every application.

We want to offer newer Qt releases as a distro-wide drop-in update for all
applications to benefit.

        Kevin Kofler