Re: Pre-compiled headers

[Zack Weinberg <zack at wolery dot cumb dot org>]

On Wed, Jan 12, 2000 at 11:19:58AM +0100, Lassi A. Tuura wrote:

> > 1. The one huge cache file arrangement.  You have one mega-header
> >    file that includes all the system headers and makes all the
> >    internal definitions you need.  You run that through a cruncher to
> >    produce the precompiled header, and #include the precompiled
> >    version.
> 
> I am for this strategy, though with a twist.  What I would ask is to
> allow precompilation itself and use of it to follow this pattern:
>   - put all relevant #includes in all.h
>   - generate all.pch
>   - run subsequent compiles with all.pch
> 
> The difference here is to allow `all.pch' to be given on command line;
> no source files should need to include `all.h'.

Yes, this is doable under scheme #1 - you'd just do -include all.pch
on the command line.  But see below:

> 2) #include "all.h" is out.  Two main reasons: too many compilers do
>    not properly support (read: real working no-bugs implementation)
>    precompiled headers, and sticking in the "all.h" will slow such
>    compiles to a crawl (including gcc today).  Second: we have a
>    rather large number of, umm, unsophisticated developers, mostly
>    scientists scattered around the world.  For a precompiled header
>    scheme to be useful for us, It Just Has To Work(tm).  We won't be
>    able to teach everybody the mysteries of umpteen different
>    precompiled header schemes I am afraid.
[...]
> 3) We have lots of code.  If a precondition to being able to exploit
>    the system is to rearrange #include statements to some common order
>    or to collect them into an `all.h' in each package, it will take
>    much longer for us to be able to use the scheme -- possibly
>    infinitely long.  IMHO separately compiled and given precompiled
>    header is much more friendly for existing code bases -- and even
>    for future coding.  (Our style also guides recommend that header
>    files include minimal other headers, not only for speed but also
>    for documentation and to avoid inadvertent dependencies.  I guess
>    this would have to be reconsidered in the light of precompiled
>    header schemes, but I would much like the precompiled header scheme
>    to also take such views into account.)

These two things make me think what you really want is scheme #2.
Some of the people commenting on that don't seem to understand that;
in scheme #2, each precompiled header depends _only_ on the original
header, and the compiler silently picks them up whenever it can.  If I
write "#include <stdio.h>" and /usr/include/stdio.pch exists and is
newer than stdio.h, it will use that.  If stdio.h includes
sys/types.h, the compiler goes and looks for sys/types.pch.  The
effect of reading the .pch version is identical to the effect of
reading the original header.  Command line #defines, order of headers
included, optimization level are all irrelevant.

The price you pay for that level of flexibility is first in increased
filesystem I/O - which you probably care about, since you're using a
network filesystem - and second in not being able to do nearly as much
work at precompilation time.  Both of those mean the speedup is less.  
Refinements of the scheme could avoid that, though.

> I suppose one question you want to ask is what exactly are you trying
> to achieve?  Are you trying to make big mega-size builds go fast,
> individual developer builds, or what?

I want *everything* to go fast. ^_^

Tell me this: would you be willing to put up with a scheme that asked
you to run one command at the beginning of a build - it might need to
know compiler switches, so this would entail modifying makefiles - but
then required no special intervention thereafter?

zw