[BusyBox] Division of work.

[Larry Doolittle]

Gennady wrote:
> The way Config.h is currently setup is somewhat of a mess. Can we
> do something like we did w/ usage? Split it up into several files:
> [ applet names, optional features, dependency rules ]
> We could create a [ program that would ] prompt the user whether
> he want to enable/disable a specific item.

I like what I hear so far.  The ordinary ASCII file format stays,
and alternative or customized tools for manipulating them would
still be easy, if someone decided to ignore the new user interface.

Once libbusybox is a reality, separating out the applet name file
has the interesting advantage that no routines depend on it, only
the link phase [*].  Adding or subtracting an applet suddenly becomes
at least ten times more responsive.

Vladimir wrote:
> See linux make config, Not Perl script :)

That's certainly in interesting base from which to find ideas
about what does and doesn't work, and what is and isn't useful.
It's also kind of a mess, and will probably be thrown out in 2.5.
The original make config dates back to about 1993, when it was
unrealistic to ask people to run perl, tcl, etc.  I think times
have changed, so ease of use is more important than being able
to use a 386/25 with 8M RAM as your development platform (which
I did back then).  I _will_ object if people start requiring the
absolute latest versions of gtk, guile, java, python, ...

I tend to stick with a core installation for about three years
at a time, so I still have RH5.2 machines around doing useful
work.  That gives me perl5, tcl8.0, kaffe1.00, python-1.5, and
a ton of other tools to play^H^H^H^Hwork with.

       - Larry

[*] You still need to run applets.h through the compiler twice to
make linkable data structures.  And of course, if the new applet
hasn't been compiled yet, that would be forced.  But, none of the
other object files is out of date: not the other applets, nor the
library, nor even busybox.o, if you pull the
   const struct BB_applet applets[]
initialization into another file, a lot like usage.c.  It might
even make sense to combine that with the existing usage.c, call
it applets.c, which would #include "applets.h" twice to initialize
the two data structures.