Re: Status of precompiled headers support?

[Ralf Wildenhues]

Hi Lance,

thanks for the feedback.

* Lance Westerhoff wrote on Mon, Mar 29, 2010 at 08:52:58PM CEST:
> 
> That's the approach I ended up taking (hacking something of my own). A
> couple of items did come up though:
> 
> (1) We support multiple compilers (icc and gcc), so having a mechanism
> that reacts differently depending upon the compiler would be great.
> There is no "standard" pch approach that we can tell, and this would
> be a good opportunity for automake to come to the rescue.

But within even GCC only, there is no standard pch approach!  There are
something like three or more alternative ways to use them listed in
  info gcc 'Precompiled Headers'

each of which would require different Automake support code, not to
speak of Automake supporting more than one of them.  The only feasible
way I'd see would be to support just the minimal set of functionality
that I can get with all supported compilers (and that may not work, I
haven't checked).

> (2) An extra added issue is since we are also using libtool, I had to
> hack in some of the extra arguments that I wasn't able to pick up from
> Automake (specifically -fPIC). That too is something that automake et
> al should take care of.

Agreed.

> (3) As you said, gcc's pch support is lacking. I did notice the
> support for a single pch per cpp file, however it does not seem to
> require that the pch file is first. In fact, there are times when it
> will pick it up later in the compile.

Above-mentioned info node states:

   * A precompiled header can't be used once the first C token is seen.
     You can have preprocessor directives before a precompiled header;
     you can even include a precompiled header from inside another
     header, so long as there are no C tokens before the `#include'.

   * Any macros defined before the precompiled header is included must
     either be defined in the same way as when the precompiled header
     was generated, or must not affect the precompiled header, which
     usually means that they don't appear in the precompiled header at
     all.

> A key rule of thumb though is to
> think about your header file ordering. This is just good practice
> though. In this case, we make sure our largest and most inclusive pch
> files are loaded in first. For example, we use a lot of boost and we
> have a couple hierarchal class structures that are used repeatedly. We
> make sure as much of the hierarchy is loaded in using our pch file and
> that this hierarchy includes most of the boost headers we require.

Yeah, boost can slow down your compile ...

> (4) There is a bug in gcc where gcc will error out if the gch file is
> loaded and it attempts to load the same header file somewhere else in
> the compile (such as when g++ loads a *.h file that also loads the
> same header that corresponds to the gch file). This is a known gcc
> bug. The work around is to use a #ifndef prior to the #include. It is
> dirty, but it works just fine.
> 
> (5) Most importantly: for some reason I can not get the gch to make
> the first time around. I must have the dependency makefile code
> screwed up or something. The first time the project builds through, it
> does not build the gch file. Weird. Unfortunately, I don't know enough
> about make's quirks to get it to pick it up.

Show the Makefile.am bits you have.  We may be able to help with that.

Cheers,
Ralf