[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: we might need a better name for ac_nonexistent.h

From: Ralf Wildenhues
Subject: Re: we might need a better name for ac_nonexistent.h
Date: Sat, 29 Nov 2008 20:22:36 +0100
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

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,

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]