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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
