On Fri, 28 Dec 2001 14:51:13 -0800, Larry McVoy <[EMAIL PROTECTED]> 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? _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
