CONFIG_SITE check failure due to shell trap exit status handling (was: autoconf-2.67 - make check failure on AIX V8BETA - 2 failures)

[Ralf Wildenhues]

* Rainer Tammer wrote on Mon, Aug 02, 2010 at 08:34:42AM CEST:
> On 01.08.2010 18:58, Ralf Wildenhues wrote:
> > * Rainer Tammer wrote on Sun, Aug 01, 2010 at 05:09:01PM CEST:
> >> this are the failures of autoconf 2.67 make check on AIX V7BETA:
> >>
> >> 213: AC_CACHE_CHECK     FAILED (base.at:478)

This one is
<http://thread.gmane.org/gmane.comp.sysutils.autoconf.bugs/7328>
and there are at least two distinct issues with the test:

For one, the exit status might be 2 not 1 (FreeBSD sh; we should fix
this regardless of the rest of this message).

For another, upon a syntax error, the shell might immediately
enter the EXIT trap (before it gets to our error message) and,
as it happens, it just might be one of those shells setting $?
to the status of the command before the one that failed (0 in
this case), so that effectively, the fact that we install a
trap causes the error to be hidden.

I figured for a moment that we could special-case the '.' command
by wrapping it in ac_if_we_exit_now_it_is_always_a_failure=1/0 so
that the trap has a way to know it shouldn't exit 0, but syntax
errors can happen in configure scripts, too, and it doesn't seem
sensible to treat them differently.

So here's a more radical idea: we could have such a notifier flag
for the bulk of the configure script (starting from where the trap is
installed).  Explicit AS_EXIT([0]) would clear the flag, but any other
exit $X will exit nonzero even if $X is 0.  This could be risky: user
configure scripts that have coped well so far with 'exit 0' (maybe they
don't care about portability to these kinds of shells?) could break.
I have no idea how common usage of 'exit 0' to end configure scripts
prematurely is.

Maybe a less radical idea is to do this hoop jumping only if the shell
is not a good one.


The least radical step would be to just modify the test group to accept
any kind of exit status and if wrongly zero, look for at least an error
message from the shell.  Eric, WDYT?

Thanks,
Ralf