Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!network.ucsd.edu!news.service.uci.edu!indigo.acs.uci.edu!strombrg From: strombrg@indigo.acs.uci.edu (Dan Stromberg) Subject: Re: 386BSD versions of sources... Nntp-Posting-Host: indigo.acs.uci.edu Message-ID: <2C87CFEE.13991@news.service.uci.edu> Newsgroups: comp.os.386bsd.apps Organization: University of California, Irvine Lines: 50 Date: 3 Sep 93 23:14:55 GMT References: <CCB4ru.7K@sugar.NeoSoft.COM> <2179@foxim.nl> <25iiki$m9a@umd5.umd.edu> In article <25iiki$m9a@umd5.umd.edu>, Mark Sienkiewicz <mark@roissy.umd.edu> wrote: >*flame on* > >CONFIGURE SCRIPTS CONSIDERED HARMFUL >------------------------------------ > >A lot of people think they are doing us a big favor by send a shell script >named "Configure" along with their program. This script allegedly figures >out everything the program needs to know about the machine you are installing >on, but oddly enough, the instructions usually tell you the *check*the*output* >from the configure script. > >The problem happens when you port to a new machine. I find the same problems >on Netbsd and HPUX-- configure scripts tend to get confused. Probably because >it is hard to write a program for a machine you have never seen. > >OK, so now instead of changing a bunch of parameters in an include file or >a makefile, I have to figure out what the configure script is doing wrong >and fix it. Or maybe I can guess what the last 75% of the configure script >would have done, had it actually run instead of bombing on the first problem. > >*flame off* On the contrary, -GNU autoconf- configure scripts are wonderful. Personally, I kind of like the other config script styles also, (better than nothing, provides examples from which to generalize...) but the autoconf stuff is much nicer already, and provides a much nicer framework for improvement. Rather than storing information like "SunOS has this and this, but doesn't have that and that", and "Ultrix has this, but lacks that", autoconf contains (ok, generates) code (/bin/sh code) to go and search for the presence and lack of "this and that". So the various system dependencies are independant of each other; if you build an autoconf package on a system that package has never seen before, but autoconf was set up to handle all the individual dependencies the package uses.. you'll probably get a working binary after make. And the gods know, there is a huge class of system variations that come up on more than one architecture, in exactly the same way. If the variation at hand isn't already known to autoconf, extend autoconf, mail your patch to the maintainers, and you've solved a class of problems across a variety of hosts, rather than just the OS you're using at the time. It'll make things easier for the next application writer, too.