autoconf, overriding results

[Bruno Haible]

Hi Ralf,

In <http://lists.gnu.org/archive/html/bug-gnulib/2009-09/msg00026.html>
you wrote:
> You are arguing for the developer case, which is fine per se, of course,
> but you are trading it for better end-user experience.  Once we accept
> that most of our macros are going to have bugs, or not do the right
> thing on some platform we may not be aware of, it isn't so clear anymore
> what is better.

This remark certainly catches one of the gripes that people have with
autoconf: once something goes wrong, the end user is lost.

You have done a remarkable job, documenting how to override individual
test results.

But is that enough? I wonder if storing the intermediate test results in
files would not be appropriate. A configure script does three tasks:
  1. It runs some tests and produces some test results.
  2. It computes variable substitutions and C defines to perform.
  3. It performs the substitutions and creates config.h.

If we take overridability by the end user seriously, there should be
a user-modifiable file that encodes the results of step 1 and is read by
step 2, an another user-modifiable file that encodes the results of step 2
and is read by step 3.

Currently, between step 1 and step 2, we have the config.cache file, but it
is turned off by default, and the architecture of the commands 'configure',
'config.status' and 'config.status --recheck' don't make it really clear that
the end user has an option between step 1 and step 2.

Currently, between step 2 and step 3, we have the config.status file, but
it is hardly user-modifiable because it is currently designed to be a shell
script, not a list of variables and values.

Bruno