[Development] Precompiled headers enabled for most modules (if you enabled precompiled headers)

[Milian Wolff]

On Tuesday 15 July 2014 08:15:55 Thiago Macieira wrote:
> On Tuesday 15 July 2014 15:32:10 Milian Wolff wrote:
> > It seems to be related to the number of jobs running, a "make -j1" seems
> > to
> > work most of the time, yet a "make -j40" on a compile cluster fails most
> > of
> > the time.
> 
> Theories:
> 1) one of the compilation processes started before the PCH-creation finished
> a) because qmake generated the wrong rules;
>  b) because you have a bug in make
> 2) the rules are right, but the PCH creation is failing due to bug in the
> toolchain

OK, but why are PCH's enabled by default? The output of configure --help does 
not indicate that. I.e. why is -include .pch/Qt5Something even passed to GCC 
in the first place by default?

> Please check all three possibilities. The easiest is to check the rules. Let
> me take the example of QtCore and qglobal.o:
> 
> .obj/qglobal.o:
> /home/thiago/src/qt/qt5/qtbase/src/corelib/global/qglobal.cpp
> ../../include/QtCore/qstring.h \
> [...]
>                 .pch/Qt5Core.gch/c++
>         $(CXX) -c -include .pch/Qt5Core $(CXXFLAGS) $(INCPATH) -o
> .obj/qglobal.o /home/thiago/src/qt/qt5/qtbase/src/corelib/global/qglobal.cpp
> 
> So there *is* a rule that makes qglobal.o depend on the PCH output for me.
> It doesn't look like a qmake bug to me.
> 
> To check if the bug is in make, you have to watch your system. When it
> enters a new build, does it halt for a second or two trying to precompile
> the headers, and *then* launch the other 40 processes? If so, it's not a
> make bug.
> 
> If the above two prove correct, by process elimination we arrive at a bug in
> the toolchain. You maintioned that this happens when you're using Icecream,
> only sometimes, and when using a high -j. I have two theories for this:
> 
>  1) creation got submitted to another machine and the transfer of the file
> back failed
>  2) creation succeeded, but icecc did not submit the PCH file to the remote
> machine to compile.
> 
> In fact, #2 and remote building is usually at odds. Teambuilder had never
> fixed that. The scripts had rules to remove the PCH including so remote
> building would work.

That does sound like a valid assumption on why it all fails on my end. I'll 
just stick to configure with -no-pch.

Thanks
-- 
Milian Wolff
mail at milianw.de
http://milianw.de