[BusyBox] Changing the way help is displayed...

[Manuel Novoa III]

Larry,

On Mon, 16 Apr 2001, Larry Doolittle wrote:
> On Sun, Apr 15, 2001 at 09:05:08PM -0500, Manuel Novoa III wrote:
> > 
> > I don't think [building a native helper program] would be that difficult.
> 
> Not too difficult.  If your only experience with makefiles is with
> native-mode builds, of course, your first attempt would probably
> break the cross-compiling case.

I'm talking about a very specific, simple tool here; just a C program to write
out the string (to stdout even... the makefile could redirect the output).  It
would not need to be optimized, etc.  All that would be required is a HOST_CC
variable in the Makefile.  Everything else should be automatic.  The only
sticking point I see is the VPATH stuff, and that shouldn't be a problem to
adapt.

Of course, you could just as easily cross-compile the tool, run it on the
target platform, and then delete the binary once you generated the file.

> > One thought that occured to me is to move away from using config.h and cpp to
> > handle configuration.   Here's one possible scheme:
> > 
> > 1) Associated with each applet would be 4 files:
> >     <appletname>.h - prototypes/extern defs for anything exported globally
> >     <appletname>.c   - the applet code itself
> >     <appletname>.usage  - the usage message text (in some easily processed form)
> >     <appletname>.cfg   - information on applet features and dependencies
> 
> I like the general idea.  Quibbles and extensions:
> 
> There may not be a reason to have <appletname.h>.  The only valid
> definition it would include is int <appletname>_main().  That can
> be generated without using a separate file.

I was considering the possibility that some applets might expose internal
functions for efficiency.  Take gunzip for instance.  I can see an argument for
having an extra busybox-internal interface.

> <appletname>.usage might better be called <appletname>.en.usage,
> since the only serious reason to not embed usage in the .c file
> (maybe preprocessed from comments) is to allow clean multi-lingual
> and non-ASCII character encodings in the messages.

True enough.

> I guess <appletname>.cfg would be a default set, that could
> be overruled by the version in the current directory.  This
> is a c-syntax file, that is #included by <appletname>.c?

Actually, probably not a c-syntax file at all.  It would be something that
could be easily processed by, say, awk to generate the necessary header files
though.

> The existing Config.h does the following:
>    1. applet selection
>    2. general system config
>    3. config for groups of related applets
>    4. individual applet config 
>    5. interlocking against bogus configs
> Of these, (1) would move elsewhere, (4) is taken up with <appletname>.cfg.
> I'm not worried about (5), it's easy enough to split out.  (2) is a
> legitimate part of a busybox-wide Config.h, but there isn't really
> that much -- BUFFERS_GO_ON_STACK and USE_DEVPS_PATCH.
> I don't know how to handle (4), except to leave it in Config.h until
> someone thinks of a convenient and productive way to pull it out.

The individual applet config stuff could go in the generated global
configuration file that the user would edit.  The scripts that read that file
should be smart enough to ignore unneeded settings.

> As part of such an effort, the format of <appletname>.cfg needs to
> be documented in detail, so that all script and GUI authors can
> have some confidence that their tools will work with all "conforming"
> applets.  I guess part of that would be a "lint" script, that would
> verify conformance of a submitted applet.

Absolutely.

> > Such a scheme would certainly make it much easier for people to integrate
> > unofficial contributed applets.
> 
> I sign on to this goal.

;-)

> > I'm also about 90%
> > finished with consolidating Dan Bernstein's code for djbdns, qmail,
> > daemontools, uscpi, etc. into one tree which uses shared libs and builds
> > against uClibc.
> 
> Awesome.  Of course, the symbol resolution stage of loading a shared lib
> will slow down the exec() process, so you will lose some of the benefits
> of Dan's performance tuning.  You should leave an easy option to statically
> link a subset of the programs (the ones that an individual site measures
> as performance-critical).

That wouldn't be difficult.  In fact, you could link individual apps with
static uClibc if you like and avoid dynamic linking all together.  Since my
primary goal was minimal size though, I was looking at shared libs.  Once I get
things finished, I plan on putting my reorganization scripts and patches up for
download.

> > uClibc really needs its own libm (next big project).
> 
> How many hours do you have in _your_ day?

Not enough.  ;-)  Seriously, I'm only talking about porting glibc's or possibly
newlib's math lib.  It's just that some of the packages I've been using need
some things from libm.  For instance, the iproute package actually needs log
an pow.

Manuel