Re: State of the new config & build system

Keith Owens (kaos@ocs.com.au)
Sat, 29 Dec 2001 13:54:04 +1100


On Fri, 28 Dec 2001 14:51:13 -0800,
Larry McVoy <lm@bitmover.com> wrote:
>On Fri, Dec 28, 2001 at 09:56:53PM +0100, Kai Germaschewski wrote:
>> A couple of months ago, I came up with an alternative to kbuild 2.5. It
>> doesn't try to have all the features kbuild 2.5 has, but solves the major
>> problems with kbuild 2.4.
>
>So has anyone looked at this? Is this a viable choice? I've heard nothing
>since Kai posted this. Keith?

I looked back through the kbuild mail for Kai's suggestions, I may not
have them all.

RFD: Tracking indirect dependencies [long]

We knocked this back and forth for a while. We both agree that
extracting dependencies after compile is correct, where we differed
was the mechanism. In fact I have currently implemented Kai's
approach (lots of little files) as a stepping stone to storing the
data in a database. It turns out that one of the reasons that kbuild
2.5 is slow is handling all the little files containing dependency
data.

[PATCH] removal of list-multi

I agree with the patch but that was December 2000, in code freeze,
and again in April 2001, AFAICR Linus had said "2.5 soon". This
patch is worth resurrecting for 2.4.

Auto detection of changed commands/flags

That was a decent fix for part of the problem, but it did not address
tracking user commands nor host compiles. It did not allow for
separate source and object trees, for read only source trees, nor did
it handle the more esoteric cases like modules being built from
multiple directories.

I am not interested in partial fixes, I want the whole kbuild problem
list to be cleared. Fixes that only solve part of the problem tend to
be filed and ignored.

Kai, did I miss any of your patches?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/