Precompiled headers

[Noel Yap]

I found in the archive talk about precompiled headers
but this talk looks like it died out 2 1/2 years ago. 
Is the work continuing behind the scenes?

I'm thinking of the following:

1. If there were an option, say --perform-includes,
that would process only the #includes, one header file
could be generated for each sub-lattice in the include
hierarchy.

Pros:
  A. Would greatly decrease the number of opened files
within a large project.
  B. Transparent to programmers but may need changing
of makefiles (see below).
  C. Since makefiles can know the dependencies of
header files, they can have the responsibility of
updating these new header files.  I think this would
imply that another flag, say --preparsed-include=path,
would need to exist so that the build may tell cpp
where these files are.  In the end, cpp doesn't need
to know about dependencies -- it'll use the preparsed
header if and only if it's there.
  D. System headers that are preparsed in this way can
be shared by everyone.

Cons:
  A. Requires a lot of disk space.

2. If there were an option, say
--keep-macro-definitions, that does everything that
cpp already does except that it keeps #define's, a
cheap form of pre-compiled headers can be achieved.

Pros:
  A. This shouldn't be a difficult change since it
should just be a matter of not doing something.

Cons:
  A. Requires a lot of disk space.

The above two have gone by the requirements:
1. Coding conventions must not be changed.
2. Large-project builds should improve in speed.
3. Small-project builds should not be affected.

Any comments?

Thanks,
Noel

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com