Re: autoconf, overriding results

[Ralf Wildenhues]

Hi Bruno,

slowly digging through all pending messages ...

* Bruno Haible wrote on Sun, Oct 04, 2009 at 08:22:44PM CEST:
> 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.

Well, that's not quite what the remark was (meant to be) about, but you
certainly have a good point anyway.

> 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.

That would be very flexible.  However, in practice, some tests are
intertwined, and depend on earlier tests' results.  If we allow
overridability in general, we need to make the user aware of them
more.  Otherwise, the user might get lost even more.

> 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.

Well that may be fixable by documentation improvements alone.

BTW, the cache variables are usable (e.g., as configure command line
arguments) without using a config.cache file; so it being turned off by
default isn't a problem.

> 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.

True.  I'm a bit hesitant to change this: config.status lives in a hot
execution path, and at least some of the ugliness of its implementation
stems from optimizing it.  Now, I know you prefer portability well over
performance (and it's good to have somebody to keep us in check on this,
too! :-)  but in order to fully open up the substitution and #define
mechanism for access, I would like to see good use cases that need this.

For example, I could probably live better with a smaller step in this
direction: e.g., config.status could allow -DMACRO=VALUE, -UMACRO, or
VAR=VALUE arguments which would override specific defines and
substitutions.  But even for this, I'd like to see good use cases first.

If we decide to go this way, we need to decide whether we go
backwards-incompatible on
 ./config.status instance_with_=_in_the_name

(which can still be instantiated with --file/--header, but that won't
work for config links and config commands), or whether we go with
something like the less intuitive but compatible `-SVARIABLE=VALUE'
for substitutions.

Thanks,
Ralf