[BusyBox] Autoconf

[Glenn McGrath]

On Sat, 06 Oct 2001 20:06:32 +0200
Neal H Walfield <neal at cs.uml.edu> wrote:

> I have recently taken a look at porting busybox to the Hurd.  Happily,
> it looks like it was written quite portable, however, there are a few
> applets that are quite Linux specific.  Most of the foreseen pain
> could be eliminated by using autoconf, however, after reading [1], I
> lost a bit of hope.
> 
> Since we are now a bit past the 0.52 release, I hope that someone
> could update me with respect to the future direction of busybox's
> configuration process.
> 
There were plans to change the build system, what is the current status of
that Erik ?

> I would also like you to take a minute to reexamine autoconf as a
> possible solution.  I am relatively sure that it, in fact, does suit
> your needs.  Let me address the two complaints that I saw in the
> mailing list archive.  The first was that a non-trivial
> (i.e. non-default) configuration would have far too many command line
> switches; this does not have to be the case.  It would be trivial to
> setup autoconf to source a file before processing the command line
> arguments (remember autoconf emits bourne shell code).  Thus, you
> could have something like this:
> 
>         enable_cat = 1
>         enable_foo = 1
>         enable_bar = 0
>         ...
> 
So we could have something like the existing Config.h (probably renamed) to
define what applets we want to compile, we would have to use something like
you suggest other than #define.

> The second complaint was that using a other tools can be quite heavy
> weight (i.e. having a dependency on python, et al).  I would like to
> take the opportunity to point out that, from the perspective of the
> user compiling busybox, autoconf depends _only_ on a posix bourne
> shell;  M4 is only require when rebuilding the configure file.  This is
> normally done by the developer.
> 

I made a feeble attempt to make busybox use autotools just as an
experiment, but im by far an expert, tried to teach myself along the way.

The big problem i see is compiling libbb, how do we make libbb compile only
the functions that a particular kernel can provide, some things in libbb
may compile but shouldnt be used, e.g. different system calls.

Do we have to wrap each libbb function in #defines with all system
dependent variables, and on top of that have manual override to turn of the
function that will compile but not run.

If we get libbb to build the build could use trial and error to weed out
applets that dont work by manually editiing the Config.h.


Glenn