On Tue, 11 July 2006 15:01:21 -0700, H. Peter Anvin wrote:
> Jörn Engel wrote:
> >
> >Not too bad in principle, but there were two problems I couldn't
> >solve:
> >1. One of the goals should be to make a compile faster, not slower.
> >Adding further includes hardly helps.
> >2. It is practically impossible to test every possible combination of
> >#ifdefs in the various headers pulled in.
> >
>
> #1 I doubt the time taken to look at include files that are #ifndef'd in
> their entirety is significant (I think there is special code in gcc to
> handle this case fast.)
Quoting Dave Jones from a few mails down the thread:
It did make a noticable difference to compiles, though I forget the
exact numbers. Should be in the list archives somewhere.
I have vague recollection that it shaved off around 20-30s, though
my memory is fuzzy.
> #2 is actually a non-issue. If each file is usable standalone (and have
> a multiple inclusion guard), then the include order shouldn't matter.
> Not that one can't create contrived cases where it would matter, but one
> can't solve every problem...
#2 was not about include order, but about things like CONFIG_SMP,
different arches, etc. As Russell King showed, breaking Arm is easier
than many people think.
Jörn
--
Don't patch bad code, rewrite it.
-- Kernigham and Pike, according to Rusty
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
