Re: [9fans] impressive

[Dave Eckhardt <davide+p9@cs.cmu.edu>]

The "old way" was to create an explicit portability layer,
with the application running on top of that layer and
one version of the layer for each platform.  So each
application would need one expert to maintain the SunOS
blob, one to maintain the HP-UX blob, etc.

The autoconf approach (following perl's pioneering
configuration infrastructure) was based on the observation
that the 1995 version of the SunOS blob and the 1995
version of the Irix blob looked somewhat like each other,
especially in the sense that if you looked at the 1998
version of each the underlying platforms had added many
of the same features.  Also, if you looked at the SunOS
blob for one application and the SunOS blob for another
application, they would of course share many similarities.

So the theory was to ignore platforms and start testing
for *features*, and the hope was that once a *feature*
had been coded for platforms would add the feature over
time and all software using autoconf would automatically
start using the feature.  Great!

But there are problems:

1. The language chosen for the configuration infrastructure,
sh, is an issue because it is REALLY hard to debug
5,000-line shell scripts which were generated by sh and
m4.  In the old days if you tried to build a package on
a too-new version of Solaris you might run into trouble
with the Solaris blob and need to contact the Solaris
expert who maintained it.  But *nobody* is an expert at
debugging 5,000-line machine-generated sh scripts, so
you just lose.

2. Feature-detection code ages very fast.  If the foo()
function used to be provided in -lmumble but suddenly is
moved -lfrobotz, or if /etc/foo.cfg is moved to
/var/etc/sbin/foo.cfg, then the test code for the foo
feature (cleverly written in m4 and turned into 237 lines
of unreadable sh) is broken.  Maybe you can figure out
how to fix it for your system, but the bad news is that
you need to fix it the same way for multiple applications
as you try to build them.

3. The interface between applications and the auto*
infrastructure changes pretty rapidly.  So if version 3
of your application is designed to work with version 47
of auto* and version 49 of auto* has better foo-detection
code, that doesn't help you at all because if you ask
version 49 of auto* to rebuild the 5,000-line shell script
to configure the application you'll find yourself debugging
amusing m4/sh errors (e.g., AC_META_FIZZBANG has been
replaced by AC_HYPER_FIZZBANG which has 7 more args
and uses a different quoting style).

The end result is that an autoconf-maintained package
will build pretty much on exactly the (platform, version)
tuples that one of the package maintainers built it on
as part of the release process, and likely not anywhere
else.

This is uncannily like the bad old days.  Furthermore,
when something is broken you're not trying to fix C code
in the application's Solaris blob, but trying to debug a
broken 5,000-line machine-generated sh script.  Sometimes
some of the application-supplied feature tests depend on
gawk as opposed to any other dialect of awk, so despite
the huge tracts of portability infrastructure actually
all of the (platform, version) tuples which work are some
flavor of Linux.  Resistance is futile!  You will be
assimilated!

Dave Eckhardt