[BusyBox] Applet mini-HOWTO (was: Syslogd and other stuff)

Larry Doolittle ldoolitt at recycle.lbl.gov
Tue Dec 19 17:43:49 UTC 2000


Matt's "Unofficial Adding an Applet to BusyBox
Mini-Mini-HOWTO" is indeed good stuff.

Let me add one paragraph, a script, and a wishlist item.

The paragraph:

If you use functions from utility.c, you may need to add to
the preprocessor conditionals in that file, to make sure the
routines you need are included.  So, since your mu implementation
used safe_read(), append "|| define BB_MU" to the #if instruction
that precedes the safe_read() function in utility.c .

The script:
----------
#!/usr/bin/perl

# multibuild.pl
# Tests BusyBox-0.48 (at least) to see if each applet builds
# properly on its own.  The most likely problems this will
# flush out are those involving preprocessor instructions in
# utility.c.

$logfile = "multibuild.log";

# Support building from pristine source
$make_opt = "-f $ARGV[0]/Makefile BB_SRC_DIR=$ARGV[0]" if ($ARGV[0] ne "");

# Move the config file to a safe place
-e "Config.h.orig" || 0==system("mv -f Config.h Config.h.orig") || die;

# Clear previous log file, if any
unlink($logfile);

# Parse the config file
open(C,"<Config.h.orig") || die;
while (<C>) {
	if ($in_trailer) {
		$trailer .= $_;
	} else {
		$in_trailer=1 if /End of Applications List/;
		if (/^\/*#define BB_([A-Z_]*)/) {
			push @apps, $1;
		}
	}
}
close C;

# Do the real work ...
for $a (@apps) {
	# print "Testing build of applet $a ...\n";
	open (O, ">Config.h") || die;
	print O "#define BB_$a\n", $trailer;
	close O;
	system("echo -e '\n***\n$a\n***' >>$logfile");
	# todo: figure out why the "rm -f *.o" is needed
	$result{$a} = system("rm -f *.o; make $make_opt busybox >>$logfile 2>&1");
	$flag = $result{$a} ? "FAIL" : "OK";
	print "Applet $a: $flag\n";
}

# Clean up our mess
system("mv -f Config.h.orig Config.h");

print "See $logfile for details.\n";
----------

The wishlist item:

Now that I unified the applet prototyping with the applet
structure definition in applets.h, only the documentation
is left out in the cold.  I understand why it might be
helpful to keep the documentation separate from the code,
and I see that Erik is uncertain as to which doc tool to
use.

As part of that decision (and work) process, let me strongly
urge that the result be a single location for the documentation,
_in_ _particular_, usage.c ought to be automatically generated
from the master documentation file.

I'm not up on the various sgml-tools issues, and I already
have plenty of BusyBox work on my plate, so I won't volunteer
for this one.

      - Larry Doolittle   <LRDoolittle at lbl.gov>





More information about the busybox mailing list