Re: State of the new config & build system

[Andrew Morton <akpm@zip.com.au>]

Legacy Fishtank wrote:
> 
> On Sat, Dec 29, 2001 at 03:44:10PM +1100, Keith Owens wrote:
> > What Mr. Fishtank seems to overlook is that kbuild 2.5 is far more
> > flexible and accurate than 2.4, including features that lots of people
> > want, like separate source and object trees.
> 
> I don't see the masses, or, well, anybody on lkml, clamoring for this.

Clamour.

The current system has some significant problems.  Pet peeves:

- Failure to rebuild the right things after you've applied a patch
- Doesn't work when the same tree is accessed via different paths
  (make dep on local machine, build across nfs)
- Mysterious recompilation of things which you've already compiled.

> IIRC from the kernel summit SGI was the only entity clamoring for this.
> 
> > Now that the overall
> > kbuild design is correct, the core code can be rewritten for speed.
> > And that will be done a couple of weeks after kbuild 2.5 goes into the
> > kernel, then I expect kbuild 2.5 to be faster than kbuild 2.4 even on
> > full builds.
> 
> Ok... you want kbuild into 2.5 ASAP, only to submit a rewrite two weeks later?

An optimisation of one bit, Keith says.  I'd guess that his two-week
estimate is optimistic because he'll have a busy two weeks supporting
the patch once it goes in, but whatever.
 
> If so it makes even less sense to get kbuild into 2.5.x now.

Keith says it speeds up builds where only a small number of files
have changed.  For me, that's the common case.

I'd like to hear more from Keith on where this 100% actually occurs,
but if he says it's fixable in a (give him four) week timeframe,
I believe him.

As you know, I'd be more concerned about moves to drop support
for the older and much faster gcc versions.  If you're not using
egcs-1.1.2, you're already a very patient person.

>         Jeff

Fish.

-