What are you talking about? If you ask GCC to compile a file with a “.h suffix, it will write out a similarly named file with “.gch” tacked on the end. And then, when something includes that file, it’ll do some checks and if everything is equal, it’ll use that precompiled header.
(Note: the words “everything” and “equal” and “use” are implementation and implementer specific and as such are subject to interpretation, discussion, reinterpretation, adjustment, argument, debate, readjustment, consideration, evaluation, re-evaluation, alcohol, burning, smiting, testosterone imbalances, puberty, intent to reach puberty within the next couple of years, rejection, dismissal, disregard, disrepect and generally anything but clear definition – if you really want to know, all you have to do is read the source code, stay up to date with the latest revisions from source control, stay active on the mailing list and nearly 40 blogs which occasionally mention gcc, its not like we get paid to do this. Thank you for choosing Open Source!)
Ok… It boils down to this. My tweaks which made the Visual Studio client build like greased lightning only seem to have benefited the Visual Studio build. The Mac project (which uses GCC) is not noticeably affected one way or the other: it takes longer than the PC build but that’s OK, as it needs building far less.
But the host project seems to be taking significantly longer. It wasn’t particularly easy to figure out whether GCC was using the precompiled header file or not, or if it is opening it, deciding not to use it, and going ahead and redoing all that work.
The host project is based on a configure.ac and a Makefile.am which builds all the targets including the libraries; I made everything use a set of standard include paths now, but each target has at least one unique preprocessor definition (-DCHAT_HOST, e.g).
Outcome: GCC uses the precompiled header but doesn’t use the contents of it because “everything” is not equal. I guess the solution is to split the host project into per-target subdirectories so that there is a per-target instance of the precompiled header.
Which is a shame, because nothing in the PCH is actually dependent on any of those defines – I was careful about that :( XCode somehow figures out how to increase sharing between precompiled headers, but I haven’t quite managed to work out what the command line for that is.
- -Winvalid-pch only tells you if the precompiled header is bad, not “different”
- -fpch-deps and -fpch-preprocess only tell you about the PCH not whether it’s being used
- In a fit of “not invented here” automake/autoconf don’t do anything vaguely precompiled headerish
- Switching to another build management tool is always an option, a long term option.