On Thursday 9. April 2015 12.34.17 Marc Mutz wrote: > 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.
Right, you are exaggerating. And that's why I don't agree with your enhanced line of reasoning. > 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? Surely it would. However at the same time I strongly doubt that the proposed changes have a significant impact on the overall build times, especially compared to the much more expensive human developer time that is spent when encountering source incompatible changes and a reduction of daytime productivity is the result. Simon _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
