From mboxrd@z Thu Jan  1 00:00:00 1970
Message-Id: <200007131601.MAA01725@egyptian-gods.mit.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Silly porting fun 
In-Reply-To: Your message of "Thu, 13 Jul 0100 09:36:13."
             <200007130836.EAA20995@cse.psu.edu> 
Date: Thu, 13 Jul 2000 12:01:14 -0400
From: Greg Hudson <ghudson@MIT.EDU>
Topicbox-Message-UUID: dae54c36-eac8-11e9-9e20-41e7f4b1d025

> i have, frequently, on Unix systems, not Plan 9.  it just has to be
> one version on (and not differing in essentials) that they haven't
> seen before.  the manufacturer tweaks an include file or moves a
> library and they fall apart.  makes you wonder why they bother to
> probe.  (made me wonder, anyway.)

Plan 9 people have an incredible propensity to focus on the occasional
failure of common Unix models and ignore the successes.  The
principles behind the autoconf model are:

	* You'd like your program to compile, on a wide variety of
	  systems, when the user types "./configure" and "make".  So
	  you don't want to do things at build time which won't
	  compile or link.  The best way to find out whether something
	  will compile or link on a given system is to try it out at
	  configure time.

	* You don't want to require builders to have special tools on
	  their system to build your program.

As long as package authors stick to these principles, autoconf works
quite well, even if it is just a kludgy collection of m4 macros.  It
doesn't matter if a vendor tweaks an include file or moves a library;
either a candidate bit of code will work on that system or it won't.
Unfortunately, not all portability issues can be handled by simply
trying to compile and/or link a finite number of code samples, and not
all package authors understand or care about the above principles, so
you get the occasional problem.  But really, I've dealt (as an
integrator) with a lot of autoconfigured programs on a lot of systems,
and I've never wished that a program didn't use autoconf.

On the other side of the coin, as someone mentioned, you can try to
make your software portable without autoconf.  That trick almost never
works well.  You invariably wind up creating a complicated one-off
system with its own weird conventions for tweaking various build
parameters.  I've played integrator for a lot of programs which take
this approach, and I've always wished that they used autoconf.

> you will have the penguin's own time working out what those scripts
> are doing, and untangling some bizarrely structured makefiles.

"Working out what those scripts are doing" is usually a matter of
looking at config.log.

Bizarrely structured makefiles are not autoconf's fault.  I've written
lots of autoconfigured packages with extremely concise and
understandable Makefiles.  They may be automake's fault, though.