Re: busybox on the Hurd
On Sun, Jun 17, 2001 at 12:49:09PM +1000, Glenn McGrath wrote:
> I had a recent discussion(1) on the busybox mailing list regarding using
> autoconf tools with busybox. My intent was to make it easier to build
> busybox under the Hurd,
This discussion does not show that they have properly considered autoconf.
There are two things to note here. First, you can use autoconf for all
porting issues and still use whatever mechanism you want to use to select
different components. Although selecting the components can be done using
autoconf in a nice way, if that way is not what they want, they can use
whatever other method and make autoconf to look up the configuration there.
The other thing is that they are not realizing what autoconf would give
them. They seem to favor a system based configuration system. "Select your
OS, [ ] Linux, [ ] BSD, ..." etc. If you are down at this level of
elegance, you don't need to ask at all, you can just use the systems
preprocessor symbols __linux__, __BSD__ etc (if you are a bit careful), or
just use config.guess, which does all the work for you.
In my experience porting literally hundred of software packages to the Hurd,
porting packages which are based on the system rather than the individual
feature components has always been very, very painful. It takes me about
ten times more time and effort to get it right on such systems, because I
have a lot of more work to do than on autoconf/feature based configuration
systems. There are several reasons why:
* Sometimes those systems are written in a mixture of system discrimination
and feature discrimination, where the features are enabled in a system
specific file. For example, a file linux.cf would enable SHARED_MEMORY, and
SHARED_MEMORY would be checked if to use shared memory on this system. But
also, __linux__ is used freely in the code to check for linux wthout giving
it a feature symbol.
This approach has two problems:
* First, when I port the package, I have to learn a wholly new
configuration system. I may misunderstand what the symbols are meant
to define, and documentation is most often lacking (exim being a nice
exception to the rule, but take a look at XFree86!). I also have to
check all explicit uses of __linux__/__BSD__ and other similar systems,
because most of the time the authors didn't get it right, and
enabled features on Linux only which are coming from GLIBC and so on.
This is a lot of extra work for me.
* The second problem is that it is harder to maintain such software.
I have rarely seen an author who will maintain the Hurd port for me
on such configuration systems, so with every couple of releases, there
are some new symbols or places where __linux__ is used instead
__GLIBC__, which I have to port again. I have to find out which new
feature macros are defined (and of course not enabled on the Hurd
configuration), and I have to check for new places where __linux__ is used
where it is not appropriate. Porting suddenly doesn't become a no brainer
anymore, because every new release has to be checked and maintained.
On such systems, it can take several months to a year to get a version that
works without changes, and this is an unstable situation, too (the next
version might be broken again).
* Because these systems often require external, system-dependant input, the
Debian packaging scripts have to be modified. Compiling it for different
systems requires different commands. You loose automatization.
* When doing the port, I don't know how the author would like to make the
discrimination I am looking for. It is likely that I will write a patch
that might not be acceptable, because I don't know the policies of the
authors wrt configuration options (when to introduce a new feature? When to
hack with __linux__?).
* When my patch is incorporated, but modified along that way, because it was
not acceptable as I wrote it, it happens occasionally that the result will
not work because of subtle differences on the system I port to the author
didn't know about.
What is my experience with autoconf based systems?
Most of them, I would say, between 75-90 per cent, work out of the box.
The critical differences are already checked for by autoconf automatically,
and the compilation runs fine. When a feature is used which is not checked
for, it is easy to add a new check, and use it in the code. I know what the
author expects, because autoconf is used in a standard way, and I know that
my change expresses my need accurately, because it is feature based, and the
feature which is checked for is explicit in the patch.
One person expresses in the thread that busybox will only compile and run on
Linux. This narrow minded-ness can be taken care of by autoconf. If you
use autoconf properly, busybox can run and compile on *every* posixish
system. I hope he didn't mean that they are not interested in being able
to use busybox only on Linux. It would be sad if the Debian installer team
locked itself in a one-system only software, which had to be forked to get
it working on the Hurd.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: