This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Pre-compiled headers
- To: gcc at gcc dot gnu dot org
- Subject: Pre-compiled headers
- From: Zack Weinberg <zack at wolery dot cumb dot org>
- Date: Tue, 11 Jan 2000 20:12:27 -0800
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