This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Problem with PFE approach [Was: Faster compilation speed]
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: jepler at unpythonic dot net
- Cc: Kai Henningsen <kaih at khms dot westfalen dot de>, <gcc at gcc dot gnu dot org>
- Date: Sun, 18 Aug 2002 16:20:14 -0400 (EDT)
- Subject: Re: Problem with PFE approach [Was: Faster compilation speed]
- Reply-to: dberlin at dberlin dot org
On Sun, 18 Aug 2002 jepler@unpythonic.net wrote:
> Let me see if I understand what people are talking about.
>
> a.h:
> /* Include header guard if appropriate */
> #define X 1
>
> b.h:
> /* Include header guard if appropriate */
> #define Y 1
>
> m.c:
> #include "a.h"
> int main(void) { return Y; }
>
> If m.c is compiled using PFE, and the PFE header contains both a.h and b.h,
> will the compilation complete successfully?
>
> If yes, and b.h is later modified to remove the Y definition will a build
> system where m.c does not depend on the PFE header actually rebuild m.c,
> since the output of m.c depends (erroneously) on an item in b.h through
> the PFE header?
A build system where m.c does not depend on the prefix header should
*not* rebuild if b.h is modified.
That's my point.
>
> My understanding of the PFE symbol implies that m.c would see a definition
> from b.h even though b.h was not the target of a #include directive.
Yes, they would be existing, but this is user error.
They should always include the right things.
In other words, you should make sure it works without a PFE header
before you try it *with* one.
It's only when you *count* on the fact that the PFE header is there that
you run into dependency problems.
--Dan