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

[Thiago Macieira]

On terça-feira, 22 de novembro de 2016 01:06:00 PST 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.

Fundamentally, no. But the important difference is the bottleneck.

I remember in the MeeGo days when building MeeGo with OBS spent an hour on a 
very beefy machine compiling Qt, with most of the resources in the OBS farm 
unused because nothing else could be built yet. With Qt 5 and our split 
packages, this lessens because only qtbase is the bottleneck.

> 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.

Again, a matter of scale. And note you said "rebuilding an application", not 
"rebuilding all KF5 and other domain libraries, then the application".

In addition, the ability to upgrade just Qt and then retest already-built 
libraries and applications allows us and distros to detect regressions and 
other issues. There's no need to rebuild everything in order to see what 
happens.

> > 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?

End users who don't develop, sure. 

If they develop something, then their self-built libraries will break and need 
to be rebuilt. I've since stopped building KDE from sources, but that used to 
be a problem with libraries that broke ABI. ICU and Boost come to mind: after 
a system upgrade, many applications would fail to load (to the point of not 
having a desktop at all) because the older versions of the system packages for 
those libs got removed in the system upgrade until I rebuilt the world. 
Granted, this can be fixed by not removing those packages during system 
upgrade.

> 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.

I can't think of anything that would be worth the major headache that breaking 
BC more often than once every 4 years would cause. And note I'm not talking 
about breaking SC.

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