From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Fri, 11 Jun 1999 15:11:55 +0100
From: Tim Goodwin tjg@star.le.ac.uk
Subject: [9fans] 9libs, new sam release, experimental wily release
Topicbox-Message-UUID: 98239588-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19990611141155.3ptX92gmZR300-sa892Yor4DWNs6G2bkN55f4B_fflw@z>

In article <199906111008.GAA08404@cse.psu.edu>,  <forsyth@vitanuova.COM> wrote:
>it would be nice if someone did a general but sane configuration method for the gnu software
>to replace the existing configure crud.

Yup.  It's effective, but not pretty.  In the rc-1.6 distribution,
`configure' is the largest file by a factor of more than 2; it is over 9
times larger than any C source file except the yacc-generated parse.c.
Both Makefile.in and aclocal.m4 are also larger than any source files;
between the three of them, they make up over 25% over the distribution.
Still, they probably compress better than most of the other files :-).

I think the approach taken by some of Dan Bernstein's software is
probably along the right lines.  Here's a snippet from the Makefile of
his clockspeed package.

    hasrdtsc.h: \
    tryrdtsc.c compile load
            ( ( ./compile tryrdtsc.c && ./load tryrdtsc && ./tryrdtsc \
            ) >/dev/null 2>&1 \
            && echo \#define HASRDTSC 1 || exit 0 ) > hasrdtsc.h
            rm -f tryrdtsc.o tryrdtsc

In case it's not obvious, this attempts to compile, load, and run
the program tryrdtsc.c.  If it can be built, and runs successfully,
hasrdtsc.h will contain the single line `#define HASRDTSC 1'; otherwise
it will be empty.

The autoconf equivalent would be something along these lines.

    AC_DEFUN(TRY_RDTSC, [
        AC_CACHE_CHECK(for Pentium RTDSC instruction, try_rdtsc,
            AC_TRY_RUN([
    <text of tryrdtsc.c goes here>
             ], try_rdtsc=yes, try_rdtsc=no, try_rdtsc=yes))
             case "$try_rdtsc" in
             yes) AC_DEFINE(HASRDTSC) ;;
             esac
     ])

It's obvious how to make the trivial changes to Bernstein's Makefile
to produce the equivalent of autoconf's AC_TRY_LINK or AC_TRY_COMPILE.
With AC_TRY_RUN, the three macros form the basis of almost all sensible
autoconf checks.

How do the two systems compare?

The autoconf version is longer, even in the configure.in version.  It
expands to about 40 lines of even more impenetrable shell script after
processing.

For all that extra code, the only extra features I can see in the
autoconf version are: i) it tells the user what it is doing, and
ii) there is "support" for cross-compiling.  Well, most users don't
have a clue what the Pentium RDTSC instruction is anyway; a comment
in tryrtdsc.c would be as helpful to those that do care.  As for
cross-compilation: autoconf knows when you're cross-compiling, and
substitutes a default value.  If there is a useful default value, why
would we bother with autoconf in the first place?  Bernstein's system
encourages the savvy installer to run the test program on the target
machine, and create the *correct* hasrdtsc.h.

Both systems feature caching.  The configure script builds a
config.cache; Bernstein simply uses make's dependency rules.  When
you are developing feature tests, config.cache is at completely the
wrong granularity.  With autoconf, I'd have to fire up an editor on
config.cache, find the line that mentions try_rdtsc, remove it, then
rerun the *entire* configure script.  With Bernstein, it's just `rm
hasrdtsc.h; make'.

Speaking of granularity, autoconf dumps all its discoveries about
the system into a single config.h.  Any C source file that needs a
feature test depends on config.h; changing the result of one test means
recompiling all of them.  (In rc's case, this turns out to be *every*
C file; I'm afraid I was a bit lazy here.)  This, of course, is why
autoconf must go through hoops to avoid replacing config.h with a newly
generated, but identical, one.

I'm seriously considering dumping autoconf / automake as the build
engine for rc(the next generation), and using something more like
Bernstein's system.  (Unfortunately, I don't think he's made the
framework generally available; I gather that his Makefiles are
automatically generated.  Still, I could probably reimplement the whole
lot in about the time it takes to get the quoting right on one autoconf
macro.)

Apologies for the length...

Tim.