proposal to start merging some source files in libbb/

[Rob Landley]

On Thursday 18 May 2006 4:42 pm, Paul Fox wrote:
> sorry, but color me skeptical that this is a worthwhile problem.
>
> busybox builds pretty quickly.  the second build after a "make
> clean" builds _very_ quickly.  why all this worry about disk
> space (too many small files) and cpu time (excessive building)?
> most developers are building defconfig or allconfig images
> anyway, and so by definition are building all the "cruft".  i
> doubt there would be much speedup for them.

It's not a question of build speedup, or disk space.  It's a question of being 
able to read and maintain the source code.

In 2003 I spent four months or so crashing on the couch in Eric Raymond's 
basement editing "The Art of Unix Programming" (for values of edit that 
include "the book was 9 chapters long when I started and 20 when I was 
finished").  And one bit I remember is that Eric tracked down some actual 
research on module size vs bug density, and it's a U-shaped curve.

http://www.faqs.org/docs/artu/ch04s01.html

The problem is how much you can keep in your head.  Something can be too big 
to keep in your head, but it can also be chopped into such small pieces that 
you spend all your time jumping from piece to piece.

>  > What would be needed is to create a list for all selected applets,
>  > iterate over them to collect a list of functions which are exported via
>  > libbb.h and use *that* list after $(sort ) as stuff to actually build.
>
> and the added complexity will probably require GNU make 4.30 to
> support it.  i'm a big fan of KISS.  on-demand linking has solved
> this problem for many years.

Go look at libbb/xfuncs.c, libbb/llist.c, and a half-dozen other files listed 
in libbb/Makefile.in.

We need more infrastructure so that these are just one line to #include from 
the Makefile rather than several, but at least we don't have to list the 
individual .o files they contain anymore...

Rob
-- 
Never bet against the cheap plastic solution.