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 <[email protected]> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
