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 [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
