Re: configure busybox

[Eric Siegerman]

On Thu, Sep 20, 2001 at 10:04:10AM -0400, Steve M. Robbins wrote:
> Hello Glenn,
> 
> On Thu, Sep 20, 2001 at 02:53:03PM +1000, Glenn McGrath wrote:
> 
> > 1) [...] there needs to be a way to only compile [libbb] functions that
> > will work on the target machine.
> 
> That is really autoconf's raison d'etre.  
> 
> Using AC_CHECK_FUNCS(f1 f2 f3 ...) in configure.ac, you end up with a
> bunch of preprocessor symbols defined in config.h.

The question then becomes, what to do with that information.  In
many projects, the answer is to compile a replacement version if
the system doesn't provide one (for things like vfprintf() or
some flavour of regex matcher).  When we're talking about system
calls like chown() or link(), of course, things aren't that easy.

One possibility (perhaps not the best one) would be to replace
such functions with versions that just return a constant error
status.  You have to get creative as to which status to return
for each system call, to follow the Unix semantics as closely as
possible.  For example:
  - link() could return EMLINK, "the maximum number of links to a
    file would be exceeded", because on a system without hard
    links, the maximum permissible link count is effectively 1.

  - chown() could return EINVAL, "the group or owner argument is
    out of range", because on a system without the concept of
    file ownership, like MS-DOS, the legal range of new owners is
    the null set; any argument except -1 is out of range.  If the
    system has owners but not groups (maybe NT? I'm not sure),
    chown() could try to do any change-owner request, but return
    EINVAL for any change-group request.

> > 2) Config.h assumes that libbb is fully functional and therefore any of the
> > commands will compile, however functions that may be required to compile a
> > specific command may not have been compiled in libbb and may be missing. It
> > would be good if a Config.h could be generated  that only lists commands
> > that are compilable, then the user could manually select what they want
> > (and will work) prior to making it.
> 
> Without looking at busybox, I can't be sure how much work it will be
> to implement what you suggest.  It sounds like you would need to keep
> track of which libbb functions are needed to compile each "command",
> which could get a bit heavy to maintain.

After a quick look at list of busybox subcommands, I don't think
it would be that hard.  Many of them only need simple file I/O,
and many more only that plus stat().  It's pretty obvious what
the "chown" and "ln" subcommands need.

A bigger issue, IMO, is simply with having Config.h be both
program-generated and user-editable.  Files like that play hell
with revision-control systems.  Other examples:
  - Smail's Makefiles, which one edits by hand, but which then
    get mkdep-style dependencies automatically appended
  - CVS's src/options.h, which is generated by an Autoconf
    configure script from options.h.in, but which is then
    intended to be hand-tuned by the user

One wants to use CVS (or whatever) to revision-control such files
so that users' edits can be kept track of, but at the same time,
all the changes made automatically are just noise, that should
NOT be revision-controlled.  Worse, rerunning whatever generates
the file (in this case, configure) clobbers any hand edits -- or
if it's careful not to, thereby fails to update the file with any
changes appropriate to the new configuration.

In the case of Config.h, you folks, as busybox's maintainers,
might not CVS-track Config.h at all, but just consider it to be
another generated file.  But I, as a (sysadmin-level) user of
busybox, would probably import it into my own CVS repo.  At that
point I'd be faced with the quandary I've described.

Another problem: the user's edits are worth preserving only
within the context of a given system/project.  If I've gone to a
lot of work to hand-tune Config.h to make an optimal busybox for
my Linux application, and then check busybox out of my CVS repo
on a Windows machine, my Config.h isn't too useful -- but I don't
want to just replace it with the Windows version since I still
need the old version for future Linux builds.  Similarly if I
need different busybox's for different embedded-Linux
applications.  (This problem is due not to Config.h's
generated+edited nature, but to its hard-wired name.  In order to
be seen by the build system, the file *must* be named Config.h;
this leads to conflict because multiple configurations
effectively need to be stored in one file.)

Besides, Autoconf is designed to provide a non-interactive build
process.  The intention is that the user be able to run:
        configure
        make
        make install
without any required editing steps interspersed.


A better way to approach this would be to pass the subcommand
list as an argument (or arguments) to configure, something like:
    --enable-chown --enable-link
    --disable-fdflush
or
    --enable-commands=chown,link
    --disable-commands=fdflush

(Not sure how to deal with the presence of both --enable-FOO and
--disable-BAR on one command line.  That might depend on what
busybox is actually used for...)

The defaults on any given platform should be: all subcommands
that can be implemented on that platform.

Unless the defaults are acceptible, this leads to a long,
irreproducible command line.  But that's a potential problem with
*any* autoconf'ed project.  My usual solution (and I think many
peoples') is to write a little shell script (batch file, etc.)
that calls configure with the right arguments, and
revision-control the script.  If someone wants multiple busybox
configurations for different purposes, they can write several
scripts and name them appropriately; no naming conflict, because
the file-name isn't hard-wired into the build system.

> You may be able to get a similar effect for less work.  For example,
> if you do nothing the link will just fail when libbb is missing a
> required functionality.  ;-)

Bad idea to ship that of course, as the smiley acknowledges.  But
in terms of building the list of functions needed by each
subcommand, this might be just the ticket.  Omit some function
from libbb (do NOT replace it as I described above); then just
keep tweaking the dependencies list and rebuilding until you stop
getting link errors.  Do the same for each system-dependent
function in turn.  You could even automate this with a script;
it'd be pretty mindnumbing to do by hand.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
The world has been attacked.  The world must respond ... [but] we must
be guided by a commitment to do what works in the long run, not by what
makes us feel better in the short run.
        - Jean Chrétien, Prime Minister of Canada