This is the mail archive of the
mailing list for the GCC project.
Re: Apple's implementation of precompiled headers
- To: Daniel Egger <degger at fhm dot edu>
- Subject: Re: Apple's implementation of precompiled headers
- From: Devang Patel <dpatel at apple dot com>
- Date: Tue, 2 Oct 2001 12:17:50 -0700
- Cc: Devang Patel <dpatel at apple dot com>, Stan Shebs <shebs at apple dot com>, gcc at gcc dot gnu dot org
On Saturday, September 29, 2001, at 04:36 AM, Daniel Egger wrote:
> On Fre, 2001-09-28 at 23:23, Stan Shebs wrote:
>> Our approach to precompiled headers has been to write GCC's trees
>> and related data into a file, using a format that can be mapped in
>> and randomly accessed. Changes to GCC are not large, mostly to
>> replace the low-level memory allocation machinery, and to add hooks
>> to both "freeze" and "thaw" GCC's internal state.
> So you are serializing GCC's trees after parsing the headers into a
> file. When this file is available at a recompilation you somehow figure
> out whether the #include lines in the code have changed and whether
> the (recursivly) included files themselves are more recent than your
> serialized file. Correct?
Yes and No, because how/when to decide if it is 'changed' ?
- content is changed
- content is same but different compiler options
- content is same but different macro settings
- content is same but different time stamp
- content is same but different file system location
Any suggestions ?
It is easy to be conservative but when total build time is 'in-hours'
of 'in-minutes', sometime it hurts to be very conservative.