This is the mail archive of the
mailing list for the GCC project.
Re: Problem with PFE approach [Was: Faster compilation speed]
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: "Timothy J. Wood" <tjw at omnigroup dot com>
- Cc: Devang Patel <dpatel at apple dot com>, Mike Stump <mrs at apple dot com>,<gcc at gcc dot gnu dot org>
- Date: Sat, 17 Aug 2002 23:15:03 -0400 (EDT)
- Subject: Re: Problem with PFE approach [Was: Faster compilation speed]
- Reply-to: dberlin at dberlin dot org
On Sat, 17 Aug 2002, Timothy J. Wood wrote:
> So, another problem with PFE that I've noticed after working with it
> for a while...
> If you put all your commonly used headers in a PFE, then changing any
> of these headers causes the PFE header to considered changed. And,
> since this header is imported into every single file in your project,
> you end up in a situation where changing any header causes the entire
> project to be rebuilt. This is clearly not good for day to day
> A PCH approach that was automatic and didn't have a single monolithic
> file would avoid the artificial tying together of all the headers in
> the world and would thus lead to faster incremental builds due to fewer
> files being rebuilt.
> Another approach that would work with a monolithic file would be some
> sort of fact database that would allow the build system to decide early
> on that the change in question didn't effect some subset of files.
Also, while constructive criticism is good and all, at some point, it
becomes "put up or shut up". It's one thing to say how great something
would be, another thing to implement it. We have heard your idea, we know
how to implement it. Everyone is aware of it. At this point, i'd
rather you tell me how good it is when you've got code to do it, rather
than keep pointing out what you perceive to be flaws in something that is
a large improvement over what exists now.
One of the things that slows down gcc development is criticism of patches
that are large improvements over what exists now, in favor of some
"better" approach, which nobody has yet implemented. Then this large
improvement never gets accepted, and nobody ever implements the "better
approach". The perfect is the enemy of the good.