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: Kai Henningsen <kaih at khms dot westfalen dot de>
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 18 Aug 2002 10:35:53 -0400 (EDT)
- Subject: Re: Problem with PFE approach [Was: Faster compilation speed]
- Reply-to: dberlin at dberlin dot org
On 18 Aug 2002, Kai Henningsen wrote:
> firstname.lastname@example.org (Daniel Berlin) wrote on 17.08.02 in <Pine.LNX.email@example.com>:
> > 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
> > > changes.
> > No, they shouldn't have any dependencies on it's contents. They should
> That would be seriously broken ...
> > 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.
> ... unless you have some mechanism to prevent them from being influenced
> by any change in any header which is used in the prefix header but which
> they do not include normally.
Why would they be influenced by a change to something they would not
Unless they don't include what they normally should.
> What mechanism would that be?
> The dependency chain is *exactly* the same as if the prefix header was
> normally included at the start of every source file.
This is wrong, and leads exactly to the problem Tim describes.
The dependency chain should *not* include the prefix header.
The fact that the prefix header exists is not something the build system
should know about, except insofar that it rebuild the prefix header when
the headers it includes changes.
> MfG Kai