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:21:27 -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:
> On Saturday, August 17, 2002, at 08:04 PM, Daniel Berlin wrote:
> > 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.
> > Um, this header should *not* be explicitly included in the files.
> > It's *prefix* header.
> I'm not saying that I'm #including it in my sources. What I'm saying
> is that the IDE knows that all my files depend upon it (they all end up
> including it due to it being the prefix header, regardless of whether
> it is listed or not). This means that they may have depedencies on the
> its contents and must be rebuilt if it or any header it includes
No, they shouldn't have any dependencies on it's contents. They should
include what they normally include. The fact that the prefix header stores the
compiler state should prevent these includes from doing anything (since
it'll know it's already processed that header) when it is present.
Any build system that makes the files depend on the prefix header is
broken, and needs to be fixed.
Prefix headers need to be rebuilt when compilation options change, or the
headers it includes change.
Files only need rebuilt when some normal header they depend on changes.
*Not* when the prefix header changes.
> The way I think about this is that the prefix header mess is just a
> hack to avoid having a #include at the top of each file. There should
> be nothing else special about the header -- it is just assumed that
> there is a #include at the top of your file.
> > The only thing that would need to be rebuilt in this case is the
> > prefix header.
> > Everything else that would normally not be rebuilt will not be rebuilt.
> Nope... everything needs to be rebuilt. The problem is that the
> prefix header might satisfy some symbol or macro that a source file
> needs (assume that the source file doesn't explicitly include headers
> it needs).
Don't assume that.
It should always do so.
If not, the source code is wrong.
It's not a usability issue that users must have the proper includes.