Still my favourite is to fix the actual error (if any) - however, I usually don't have this trouble. But I also don't know what is different, except the platform (Windows / Linux).
This is another matter and it is unrelated to the disabling of pch.
I think whatr Morten wants to say, is to fix the bug, that leads to the problems with pch's.
And that is not unrelated to disabling them in general.
Yes, that's what I meant - find the reason why it doesn't work an fix it. However, as it seems to depend on the platform it may not be our fault at all, but the compiler used could be another reason. And the fact that I can hardly reproduce on Windows makes me believe so.
In fact what we do is plain right: If the header file is set to be compiled first (which is is due to the weight) and it has changed (which we figure out by its date and dependencies) it will be re-compiled. The rest is done by the compiler.
Reasons why it does not work maybe:
1.) The date is wrong
2.) The dependencies are calculated wrong
3.) The compiler pre-compiles wrong
4.) (for me most likely) when we start build processes in parallel we don't consider a special handling for PCHs. Consider you start 3 build processes, where the first two are the PCH's and the next one is already part of the SDK.
However, if 4.) is true it should
always work in a second trial.