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

Larry Doolittle ldoolitt at recycle.lbl.gov
Mon Apr 16 21:19:11 UTC 2001


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

The shared core of gunzip has now moved into libbb/, to keep the applet
interface clean.  I'd rather have the linker pull the right routines in
from libbb.a, than deal with various applet dependencies and interlocks,
like that mess at the end of Config.h.

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

You can certainly use awk (perl, python, snobol) to parse a file
that is also c-syntax.  The parsing programs can either look at the
raw foo.cfg file, or the result of some gcc munging of that file,
like busybox.mkll and busybox.sh do.

The big advantage I see of keeping local configuration local (rather
than aggregating it into a single Config.h, either natively or as
part of a Makefile rule), is to make it quick to rebuild after a
sudden change of heart on how you want it configured ("oh, s***,
I really do want ifconfig status support").  There's no technical
reason why any files except ifconfig.o and busybox should depend on
that configuration choice.

> I plan on putting my reorganization scripts and patches [for djb-ware]
> up for download.

I look forward to seeing that!

       - Larry





More information about the busybox mailing list