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

Simon Hausmann simon.hausmann at theqtcompany.com
Fri Apr 10 13:38:55 CEST 2015


On Thursday 9. April 2015 14.40.11 Marc Mutz wrote:
> On Thursday 09 April 2015 12:46:11 Simon Hausmann wrote:
> > > 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 was exaggerating when proposing to include <QtFoo> in each header.
> 
> I was _not_ exaggerating when I said that by your (plural) line of
> reasoning, we'll slowly accumulate cruft in every header that will hurt
> maintainability and compile times. Just look at what qglobal.h includes to
> stay SC. It's ridiculous. Even worse, it's not enough. For
> https://codereview.qt- project.org/106680 I'm still fighting with myself
> because I'd need to add <qtypetraits.h> to <qglobal.h> and rearrange some
> code in qglobal.h to be able to use QEnableIf as early as qRound().

Yes, over time we will accumulate cruft. We must indeed be very careful what 
we put into public header files.
 
> > > 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.
> 
> The problem is not this one change. The problem is the cumulative regression
> in compile time that ensues when we're not even allowing include changes
> that only break clients that rely on indirect includes.
> 
> It's easy to prevent these breakages user-side by applying a tool like Ossi
> posted in one of the changes:
> https://code.google.com/p/include-what-you-use/
> 
> As Andre said, which header includes which other headers isn't even
> documented, so it's an implementation detail. Implementation details are
> subject to change.

Implementation details are details that you can change without affecting the 
users. The proposed changes however do affect the users. In my opinion the 
"clean up" isn't worth the damage it does, as I explained in my original 
reply.


Simon



More information about the Development mailing list