[Development] Are SiCs through #include cleanups considered acceptable?

[Marc Mutz]

On Thursday 09 April 2015 10:39:57 Simon Hausmann wrote:
> On Wednesday 8. April 2015 14.34.03 Olivier Goffart wrote:
> > On Wednesday 08 April 2015 13:13:19 Marc Mutz wrote:
> > > Hi,
> > > 
> > > I have in the past fixed #include mistakes such as #include
> > > <qsharedpointer.h> for QSharedDataPointer, and even though each time
> > > the issue came up that this is a SiC change (but only for users that
> > > unduly rely on indirect includes), so far they were always accepted.
> > > 
> > > When splitting off qHash() from qhash.h into qhashfunctions.h, I have
> > > come across many files that included qhash.h without using it, and
> > > likewise some
> > > for which qhashfunctions.h would suffice. One of them now got a -1 for
> > > being SiC.
> > > 
> > > Can we please decide once and for all whether #include cleanups that
> > > are technically SiC are ok or not, if they only affect users that rely
> > > on indirect includes?
> > > 
> > > My vote obviously goes to allowing them.
> > 
> > My vote goes against such gratuitous SiC changes.
> > 
> > Each little SiC changes add up in frustration for the developer who
> > upgrades its Qt version.
> > So when it is easy to avoid, we should avoid it.
> 
> I'm with Olivier on this one. Source compatibility is a key contribution to
> the success of Qt.
> 
> For developers building their own software it may not be such a big deal,
> if they are experienced Qt developers. For somebody who just clones a
> random project off github and then tries to build it, such a "simple"
> source incompatible change becomes a deal breaker. I argue that there's a
> high probability that person is not familiar with these types of changes
> nor knowledgeable how to fix them.
> 
> I've encountered this numerous times myself for example trying to keep the
> nvidia modules on my Laptop compiling with a changing kernel API. Often the
> fixes are _absolutely_ trivial one liners about missing includes. But I
> more often can't be bothered to dive into the source code to figure out
> what to add where. And then we have exactly the element of frustration
> that harms the product.

So, by this line of reasoning, the list of #includes in a public header file 
must be a monotonically increasing function of the Qt version. Since we're 
keeping SC even across major versions these days, we'll thus slowly converge 
on including all of a Qt module's headers in each of its headers. So, why 
don't we shortcut the process and include <QtFoo> in each QtFoo-module's 
header _today_? :)

I'm exaggerating, of course. A bit, at least.

I wonder: wouldn't it also harm the project if people who use Qt for a living, 
pay your salary by buying licenses and have to spend X amount of money on 
additional hardware just to make the nightly builds actually build in just one 
night started to look for alternatives?

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts