[So far, I've generally been trying to keep away from the hot topics, but I guess it's about time to make that experience. Also, let me add that my opinion here is of course influenced by the fact that things didn't go the way I would have liked...]
On Fri, 28 Dec 2001, Keith Owens wrote: > On Thu, 27 Dec 2001 17:15:45 -0800, > Larry McVoy <[EMAIL PROTECTED]> wrote: > >[talking about kbuild 2.5 speed] > >Then it does seem reasonable to ask that the new one is at least as fast > >as the old one. > > kbuild 2.4 is fast but inaccurate, kbuild 2.5 is slower but accurate. > Pick one. Most problems which exist within kbuild 2.4 are fixable without the elaborate rewrite Keith did. The single biggest problem the current system has is that modversions get screwed up, since dependencies are screwed up, and yes, that's not easily fixable. However, this problem isn't even attacked in kbuild 2.5 AFAIK (I think modversions are simply disabled there). 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. It definitely has things in common with kbuild 2.5, it also uses the "non-recursive" approach, i.e. the top level Makefile includes all the others. It also doesn't have "make dep" but builds dependencies with "gcc -MD" plus postprocessing. I'm not claiming it is complete, and it doesn't even try to add the multiple source tree etc. features. Others said one should use proper version management instead, and I agree with that, but that's not the point. Non-complete list of pros/cons: o gets dependencies right, i.e. a new make "whatever" will really rebuild everything which is needed. Even *with* CONFIG_MODVERSIONS turned on. o uses standard tools. I believe people said that one of the advantages of UNIX is that you don't need specialized tools for everything, but combine existing tools to reach your goals. The new kbuild has the disadvantage that most is implemented from scratch, the meat is in C programs which probably nobody apart from Keith is familiar with. My solution used the standard tool for building, i.e. make + standard utilities like sh, sed, grep and the like. I only have one non-standard tool, that postprocesses a dependency list: replace include/linux/autoconf.h with the /include/linux/config/options - this is needed so that a .config change doesn't cause an entire rebuild every time. o It's actually pretty fast. On my laptop, the time to read all the dependencies when doing a "make bzImage modules" is was about 5 seconds with hot caches. That means a make takes about 5 seconds when there's nothing to do - that's good enough IMHO. When doing a full rebuild, the time spent within make is definitely down in the noise, if only a few files get rebuild, it's noticable, but still faster than what the current kbuild system gives. o The Makefiles in the SUBDIRS look basically the same as currently, only a somewhat simpler (no special $(LD) rules for composite objects etc). Keith implemented a whole new language - I supoose most coders are familiar with normal Makefiles, they have yet to learn the new commands in kbuild-2.5 (which, however, is easy, of course) o It's not nearly as feature-rich as Keith's approach is. o Behind the scenes, the code is not exactly clear. make is pretty flexible, but it really needs some hacks to do what's needed. So if someone wants to understand the build system, it takes some effort - same situation as in kbuild-2.4 and -2.5, though. o I had the major problems solved and things worked fine in my tree. However, I discontinued to work on it months ago, as I saw no way this work would ever be useful for other people - maintaining a build system just for personal use is a bit too much effort. I don't claim that my work is superior to kbuild-2.5 or anything. (I still think it may be "good enough", i.e. does solve the current problems - it doesn't add features, though). But I'm dissatified that there never ever was even consideration. When I posted ideas/patches to kbuild-devel, I usually got a response like "this work isn't needed, I developed kbuild-2.5, which will be the solution to all problems in 2.5". I also submitted non-intrusive changes for 2.4, which fixed/simplified things there without breaking anything, but the answer was about the same, "kbuild-2.4 is obsolete, for 2.5 it's irrelevant". Well, 2.4 will be around for some time I guess... When I replied (with technical arguments), I never heard anything back - compare the current thread about just silently dropping mails/patches ;-( That's why I decided to drop out of the kbuild business again. (BTW: note that this was about kbuild-2.5 only - nothing to do with CML2) --Kai _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
