Re: State of the new config & build system

[Kai Germaschewski]

[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 <[e-mail]> 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