Re: PCH [Was: Re: Target FUNCTION_{PRO,EPI}LOGUE question]

[Geoff Keating <geoffk at geoffk dot org>]

Neil Booth <neil@daikokuya.demon.co.uk> writes:

> Geoff Keating wrote:-
> 
> > OK, here's a high-level overview.
> 
> Thanks.
> 
> > The precompiled header mechanism works by:
> > 
> > - `compiling' a header ('foo.h'), as if it was a normal .c file
> > - just before finishing the compilation, saving GCC's state
> >   (including all interesting global variables, the contents of the .s
> >   file so far, and lots of other stuff) to a file named foo.h.pch
> > 
> > - when a file is compiled, and cpplib looks for foo.h, if it also
> >   finds foo.h.pch, and if this is (more or less) the first thing
> >   in the compilation, it restores GCC's state to where it was before
> > - and continues without including foo.h.
> 
> How do you handle conditional compilation that depends on earlier
> macro definitions and / or command line switches?

If there is a macro for which:

- It is defined differently when building the PCH and using it; _or_
- A macro is defined when using the PCH that would have been used
  in the PCH, but was not defined when building the PCH,

then the .pch file is not used.  This includes macros defined by default,
which catches a number of command-line switches (like -fsigned-char).

Command-line switches are presently not treated this way.  The user
must be careful not to do anything which would cause trouble, which is
most easily done by always using the same switches.  The reason
they're not treated this way is that _some_ of them are known to be
safe, and in fact it seems possible that the majority of them are safe,
but it's hard to work out which ones, so this was left for future design.
If any particular switch is causing problems, there are hooks left in
to allow it to disable use of the .pch.

There is also a version number (actually a hash of lots of stuff, like
type layouts) in the PCH file which is checked for before using the PCH.

-- 
- Geoffrey Keating <geoffk@geoffk.org>