Re: configure busybox

[Pavel Roskin]

Hi, Glenn!

> Hi, im trying to make a project im involved with
> (http://busybox.lineo.com/) more portable, specifically i want to make it
> compile under GNU/Hurd as well as linux.

NetBSD and QNX (Neutrino and classic 4.x) would be the real challenge -
they are widely applied in embedded systems.

> My initial thoughts were that autotools would be ideal, but busybox is an
> unusal project and im unsure how to go about it.

I also considered this idea some time ago.  The biggest problem it that
configure doesn't normally read any configuration files.  You just give
options to configure, but it would be a nightmare to type someting like

./configure --with-fsck-minix --without-chmod --with-fancy-tail ...

especially because configure won't warn you if you make a typo.

However, you could convert Config.h to a file that can be interpreted in
the shell code in configure.  Consider e.g. this format:

# addgroup command
#BB_ADDGROUP=1
# cat - output and concatenate
BB_CAT=1
# Enable tab completion in the shell.  This is now working quite nicely.
# This feature adds a bit over 4k. Only relevant if a shell is enabled.
#BB_FEATURE_COMMAND_TAB_COMPLETION=1

This way, the config file could be executed in the shell running configure
(just like it loads config.cache).  The you could use AC_DEFINE to creat
what is now Config.h.

I suggest that you don't use those defines in libbb too much, but rather
rely on the linker to pull the necessary functions (I understand it's how
it works now, but just in case).

> The problems i see are;
>
> 1) all libbb files are compiled, however some have system calls that
> obviously depend on the linux kernel (and other portability problems),
> there needs to be a way to only compile functions that will work on the
> target machine.

I believe that it's not so important to disable some _commands_ (not
functions) based on the availability of the underlying system calls.

It does make sence to have non-functional chmod (although I hate
non-functional Solaris cc).  Conversely, if you are concerned about the
binary size, you can disable chmod on any OS, the only difference is just
how much space you are saving.

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

This means an additional step.  You configure the system, then ask the
user to intervene, then do some post-configuration and compilation.

It's not an unreasonable requirement given that busybox users are
embedded systems professionals, but I still don't like this idea.

> Is it a bit ambitious to expect autotools to be able to handle this sort of
> setup, in the short term its probably easier to manually port/fork busybox
> to another architecture, but the best longterm solution would be if
> autotools could be made to handle it.

Autoconf doesn't have standard support for configuration files, but you
can use shell commands in configure.  You can even use sed and awk to
parse the config file - it's considered portable.

> Does anyone have any advice, or examples of similarly situations in other
> projects ?

You would encounter the same problem it you tried to apply Autoconf e.g.
to XFree86 or to Linux kernel - Autoconf doesn't scale well if you have
too many configuration parameters.

Last time I checked, GGI was using some mix of Autoconf and Linux-style
manual configuration.  The homepage of GGI is http://www.ggi-project.org/

-- 
Regards,
Pavel Roskin