This is the mail archive of the
mailing list for the GCC project.
Re: Faster compilation speed
- From: Noel Yap <yap_noel at yahoo dot com>
- To: Neil Booth <neil at daikokuya dot co dot uk>
- Cc: Mike Stump <mrs at apple dot com>, gcc at gcc dot gnu dot org
- Date: Sat, 10 Aug 2002 15:54:23 -0700 (PDT)
- Subject: Re: Faster compilation speed
--- Neil Booth <email@example.com> wrote:
> Noel Yap wrote:-
> > I don't see this as too big a problem. Just
> output a
> > file like:
> > #if COND
> > /* contents of header file
> > #endif
> > In fact, doing it this way has the advantage that
> > several builds, not necessarily agreeing on the
> > of COND, can use the file.
> Hmm, and what about header guards? Infinite
Unless I'm missing something, header guards by
themselves shouldn't pose a problem.
You're right. Cyclic dependencies would throw this
whole thing out of whack. OTOH, I think such practice
needs to be avoided anyhow.
Another case related to recursive includes is where
each level of recursion would have side effects (eg
redefining a macro whose value is used in the next
recursion). Again, I've heard this usage only once
and even the creator of such a header file said it was
a tremendous hack for programmers with no proper
education in programming (IIRC, they were physicists).
> > I think one needn't preprocess everything
> perfectly in
> > order to gain significant advantages. Would you
> > that what I suggest is better than what we have
> Correctness is paramount; if it's not correct it's
I apologize if my post was misunderstood. What I
meant to say was, if it's able to preprocess, then
allow it, otherwise, don't. IOW, those already
following common practices can take advantage of a new
feature, those that don't have what they have now.
I can certainly understand the ideals of keeping the
tool and all its features pure and working for all
possible uses. OTOH, doing so may prevent practicle
avenues that possibly 99% of users can benefit from.
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs