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

Tom Cameron TCameron at stmarysbank.com
Mon Apr 16 21:00:26 UTC 2001


Larry and The Gang,
	I'm glad to see that everyone has seen a use for such a change.
My initial thought was to cut down on size...then I began thinking about
multi-lingual systems (We Americans think of nothing but our own
language...so it was a completely new experience for me).  I also began
thinking about developers adding their own content at compile time (if
we allow custom applets we should certainly allow custom help).  To me,
it made sense.  Anyway, I think issue (4) is addressed by this also.  If
each applet has it's own included file, the makefile can "look" for
these files.  At such a time I think it would be beneficial to have a
"basic" set of configuration data in the root of the BB directory, and
then a config directory, which could contain all pertinent information.
	I think that BusyBox has gained quite a bit of wide acceptance
in the embedded field, but there is still a long way to go for
"international" acceptance.  MANY of these internationalization issues
would be solved by using such a help system (as you stated).  It would
also allow documentation maintenance to separate itself from code
maintenance (I can work my way through C code, and write programs that
most would laugh at, but I can certainly document command line options).
I believe that moving to a fully separated help "file" would really make
things easier on developers and maintainers.
	As far as file format is concerned, using a flat file delimited
by some character would work well, I think.  Tab separated or something
of the such.  It would have to be something simple to generate with sed,
or some other utility.  Maybe something of the sort:

##### Begin FakeFileFormat #####
:BEGINHELP
    :AR    This would be the help text\nfor the AR Applet.\n
              Should we use C style markup,\n
               or would this create too may headaches?
    :SomeOtherApplet    This would be\n
                                    some other applet's help text.\n
The usage string 
                                   could be included, along with some
general textual \n
                                   info (a more indepth help blurb,
etc.)
:ENDHELP
##### End FakeFileFormat #####

	Just a thought.  Let me know what you all think.

--
Thomas Cameron
Network Technician / Operations Specialist
St. Mary's Bank

> -----Original Message-----
> From:	Larry Doolittle [SMTP:ldoolitt at recycle.lbl.gov]
> Sent:	Monday, April 16, 2001 12:45 PM
> To:	Manuel Novoa III; busybox at busybox.net
> Subject:	Re: [BusyBox] Changing the way help is displayed...
> 
> 
> 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
> 
> 
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/mailman/listinfo/busybox





More information about the busybox mailing list