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

["Timothy J. Wood" <tjw at omnigroup dot com>]

On Friday, August 16, 2002, at 01:43  PM, Devang Patel wrote:

> In both cases work around is same. A file needs to undef, as I 
> explained in previous email.
  I didn't see that on the PB list before I posted to the gcc list :)

  At any rate, this seems like a horrific and non-obvious workaround.  
This is a support burden waiting to happen.  (Of course, this header 
usage is silly, so I'm reaping the foul returns of the Win32 header 
design :)

  Actually, it doesn't seem to work for me either... I'll take this up 
on the PB list, though...

> It is a different model. All models which follows prefix header 
> mechanism, will behave same as PFE.
  True.

  I'm not a fan of prefix headers in general, certainly not for huge 
globs of crud like a PFE.  As a stylistic issue, I really only like 
prefix headers for replacing simple -D flags on the command line and 
such.

  I still maintain that the developer should not have to build and 
maintain a massive header for their project -- the IDE/compiler should 
deal with it transparently.  This falls into the Achilles Heel area of 
free software -- moderately experienced developers can figure this 
stuff out, but Joe Bob is going to sit down with gcc and see that his 
project builds slowly and switch back to his proprietary compiler.  
Ease of use is important.

  The fact that you have to build this massive single header that acts 
as a prefix header is the broken part -- implementation details like 
this should not be exposed to the user.  Just like Apple doesn't make 
users manually configure their Apache server for personal web sharing, 
Apple shouldn't make their developers do a bunch of work to get decent 
compile speeds.  It should "Just Work (TM)".

  Clearly this is the ideal, but maybe it is too hard to realize this 
ideal.  I'd feel remiss if I didn't point out this flaw in the PFE 
approach, though.

-tim