Re: KBuild 2.5 Impressions

[Daniel Phillips <phillips@bonn-fries.net>]

On Friday 31 May 2002 02:13, Kenneth Johansson wrote:
> On Fri, 2002-05-31 at 01:19, Daniel Phillips wrote:
> > There is exactly one valid objection I've seen to kbuild 2.5 inclusion,
> > and that is the matter of breaking up the patch.  Having done a quick
> > tour through the whole patch set, I now know that there are some
> > easy places to break it up:
> > 
> >   - Documentation is a large part of the patch and can be easily
> >     broken out.
> > 
> >   - The makefile parser, complete with state transition tables etc,
> >     lexer, and so on, breaks out cleanly (sits on top of the db
> >     utilities).
> > 
> >   - Executable programs written in C.  Each one ends with a
> >     'main' function, and there is the natural division.
> > 
> >   - The remaining C code breaks out into a number of separable
> >     components:
> > 
> >       - Utilities such as environment variable parsing, canonical
> >         name generation, line reading, line editing etc.
> >       - The database 
> >       - File utilities that use the database (e.g., walk_fs_db)
> >       - Dependency generation
> >       - Global Makefile construction (command generation etc)
> > 
> >     These tend to be common to a number of the executable programs,
> >     and so have the nature of library components.  They can all go
> >     under the heading 'lib', and further breakdown is probably not
> >     necessary.
> > 
> >   - The Makefile.in patches seem to be about 30-40% of the whole
> >     thing, and imho must be applied all at the same time.  However,
> >     they break up nicely across subsystem lines (drivers, fs, etc)
> > 
> >   - The per-arch patches are already broken out, and are short.
> > 
> > I think that with these breakups done the thing would be sufficiently
> > digestible to satisfy Linus.  Now that I think of it, Linus's request
> > for a breakup is really an endorsement, and quite possibly Keith took
> > it the wrong way.  (Keith, by the way, how did I do on the structural
> > breakdown?  Sorry, I really couldn't spend as much time on it as it
> > deserves.)
> 
> Maybe I'm the idiot here but what dose this gain you??

It makes it faster to analyze.  I would have appreciated that in doing
my own analysis.  If Linus incorporated the whole thing without analyzing
its structure, I'd be worried.

The only problem would be that this kind of breakup and convenience of
applying the patch tend to be mutually exclusive.  I suppose that could
be solved with a script Keith's end - simply append all the broken-apart
pieces into one large patch (in fact, it seems that two of the tree
patches you need to apply for the i386 version would be better appended
together for the purpose of distribution.)

The question of how much work it is to do the breakup itself is separate.
In my experience, maintaining a system in a broken-up form tends to be
a major use of time.  It's something you want to do once, just before
inclusion, and that seems to be exactly what Linus has asked for.

> The reason to break up a patch is not simply to get more of them. There
> is no point in splitting if you still need to use every single one of
> them to make anything work. 

See above.  It's all about analyzing the structure of the patch.  To be
fair though, it took me less than an hour to get a pretty good idea of
how the current patch set is structured.

-- 
Daniel