This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Pre-compiled headers


So, Cygnus has contracted me to implement precompiled headers.  There
are a number of different ways to do that, so before I start coding I
wanted to solicit opinions from the list on what would work well.

Whatever gets done will be done in the context of cpplib, and the
first step is probably to make --enable-c-cpplib the default and shake
out the remaining bugs.  If there are no objections, I would like to
do that this week.

There's two different precompilation schemes I can think of:

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.

   Advantages: Can be implemented soon, at least in the C++ front end
   (mash together cpp -dM, cc1plus -fdump-translation-unit, and a few
   loose ends).  Code in the headers can be processed all the way to
   tree generation.  You only read one additional file per source file
   and don't have to do any searching.

   Disadvantages: Doesn't apply easily to any other project structure.
   Won't work with C till that front end is converted to
   function-at-a-time.  Requires modifying code (to #include "all.pch"
   instead of individual headers).

2. The individual headers arrangement.  Each header you're interested
   in is run through a cruncher separately.  The precompiled version
   is tokenized but not macro-expanded.  If you're doing this to a
   directory full of headers, like /usr/include, you can glom all the
   individual headers together into a pak file.

   Advantages: Implemented entirely within the preprocessor, so works
   with all front ends.  Works with any project structure you like.
   Requires no modifications to source code.  Could be run on
   /usr/include to speed up things for everybody.

   Disadvantages: Less work can be done at precompile time, so won't
   be as fast.  Unless you have pak files, requires just as much
   filesystem trawling and I/O.  Needs a *lot* of work inside cpplib
   first (work that has to be done anyway, though).

Neither scheme necessarily excludes the other, of course, and there
may be something I have not thought of.

Incidentally, has anyone written code to reread the output of
-fdump-translation-unit yet?

zw

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]