httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@gonzo.ben.algroup.co.uk>
Subject Re: conditional HTML
Date Tue, 16 Apr 1996 23:25:38 GMT
> 
> Ben> Since I work on a platform that is typically not supported by the
> Ben> latest and greatest versions of anything I guess I see configure
> Ben> at its worst. And that is pretty bad - I can't think of a single
> Ben> large program where I haven't had to hack configure (and usually
> Ben> the source, too) and some of them have taken many hours of work.
> 
> Ben> The bottom line is that I like the idea of configure but
> Ben> experience has taught me that configure doesn't actually
> Ben> implement that idea, so I wonder what is the real advantage (as
> Ben> opposed to the intellectual advantage) of configure over the
> Ben> current hard-wired approach?
> 
> Ben> I actually think that the neatest approach would be to find ways
> Ben> to autodetect the platform (rather than attempting to detect its
> Ben> features) and use that to invoke the appropriate hardwired setup.
> 
> Ok, after talking to some of the engineers here at Cygnus (who have a
> LOT more experience with autoconf and configuration in general than
> I), I think I have some responses to the above.
> 
> First, no one here has had your problems using autoconf-based
> configure scripts on any machine.  To quote the estimable Ian Taylor:
> 
> Ian> I've never seen any Unix like system for which autoconf fails.
> Ian> The closest is Lynx, on which /bin/sh isn't good enough and you
> Ian> need to force the use of bash.  autoconf configure scripts even
> Ian> run on Steve's NT port.
> 
> In particular I've heard back that SCO builds generally work ok (at
> least for the stuff we do).  If you have details about which programs
> failed, and how, I'm sure the maintainers would love to know about
> it...  as would I.
> 
> Second, the consensus here seems to be that the idea of using the
> architecture to select a configuration file is flawed.  Until
> relatively recently, gdb did this.  They moved it to autoconf because
> people seemed to think that doing feature tests was better.  The idea
> is that if you use feature tests, you can port to machines that have
> never been seen before, without any editing at all.  Ian tells me that
> this isn't just blowing smoke: he maintains a version of UUCP that
> works on many systems -- but he has only ever tested on four.
> 
> The reference to "Steve's NT port" is also interesting: Steve
> Chamberlain works on the "Cygwin32" project, an attempt to provide
> POSIX-style functionality on NT/Win95 boxes (URL available if anyone
> is interested).  He says he has ported *many* (list appended) programs
> to NT with no (or minor) changes.  If all these packages used
> architecture-based configuration schemes, he would have had a lot of
> work to do (make a config file for each package).
> 
> Fred Fish reports something similar:
> 
> Fred> They also run unchanged on the Amiga OS when using the Unix
> Fred> emulation shared library and tools linked to it.
> 
> Not all of the programs thus ported are trivial, either -- "bash" and
> "make" are probably both more complex than Apache in terms of both
> functionality and portability requirements.  (BTW Steve claims that he
> could probably port an autoconfiscated Apache to NT using the Cygwin32
> suite with little effort.)
> 
> Also, from a maintenance perspective, I think that Autoconf imposes
> less of a burden than a architecture-based system.  With Autoconf, if
> you make a change that affects portability, you can update the test in
> one place and be reasonably confident it will work on all the
> supported machines.  With the other system, you must edit every single
> machine description and hope you get them all right.

If you want an example, I seem to remember emacs 19.30 was quite painful to
port to SCO 5. I suggest you try it.

It was worth it, though ;-)

Cheers,

Ben.

> 
> Tom
> -- 
> tromey@cygnus.com                 Member, League for Programming Freedom
> 
> From Steve Chamberlain:
> 
> These are the FSF packages that I've ported to cygwin32:
> 
> bash-1.14.6 bison-1.24 utils-2.7 fileutils-3.12
> findutils-4.1 flex-2.5.2 gawk-2.15.6 gawk-3.0.0 grep-2.0 gzip-1.2.4
> indent-1.9.1 less-290 m4-1.4 make-3.74 patch-2.1 
> sed-2.05 sh-utils-1.12 sharutils-4.1 tar-1.11.8 textutils-1.13
> textutils-1.14 time-1.6 v105
> 
> In many cases, it was sufficient just to type make, but I do 
> have some diffs for others.

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.

Mime
View raw message