Hi Eric, * Eric Blake wrote on Sat, Nov 29, 2008 at 07:34:47PM CET: > According to Ralf Wildenhues on 11/29/2008 11:02 AM:
> > ac_this_header_should_not_exist_so_an_error_about_it_is_expected.h? > > ac_force_compilation_error.h? > > Or maybe a fix is overkill. > > If it makes life easier for the person reading config.log, then I could > see making a change along those lines. I don't see a name that could fix the language barrier here for good, no. One recurring related problem though is that the "see config.log for details" is an error message that users don't grasp. And even if they do, and even with the "in $directory:" change we added a while ago, there are two more hurdles that seem difficult to overcome for many: to find the right config.log file, and to find the right error message within that file. This is not easy: GCC's configury produces several config.log files. Inside a config.log, a critical error is typically not the first encountered compiler error, and neither is it at the very end (due to possibly lots of substitutions and defines that are listed afterwards). Letting configure output that critical error on stderr is problematic, too: it's rather useless without the conftest.c that caused it, which itself may be quite lengthy. Also, it may well be that that last compile wasn't the one that really made things fail. Also, with source and error output, the context of "this is a failure within a configure test" may easily be lost.[1] Anyway, I don't see good ways to improve here. Any change that causes more verbosity is only good if it doesn't also cause more confusion down the road. More isn't always better: OpenMPI generates a config.log file almost 1MB in size, with 540 cache variables, 950 output variables, and 470 defines. The contents of the failed programs posted in config.log, which are of course important for debugging one such failure, takes up 20K lines due to all the #defines (and the inherent superlinear growth in such lines). When a chatty compiler like xlc is used, config.log contains several copies of the (long! basically its man page) `$CC --help' output, when an unknown command line option is used. In the end, this makes the log file almost unusable for newcomers and less easily usable for everyone. Oh well. Cheers, Ralf [1] `make' semantics add to this problem, too, when for example one instance of a parallel build fails, and the `waiting for unfinished jobs' causes thousands more lines of output before actually exiting.
