[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