This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem with PFE approach [Was: Faster compilation speed]


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]