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

[Larry Doolittle]

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 don't
> think it is unreasonable to assume that someone willing to cross-compile
> busybox would also have the tools to build native applications.

I agree.

> 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.

<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.

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?

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.

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.

> 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).

> uClibc really needs its own libm (next big project).

How many hours do you have in _your_ day?

     - Larry