* 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
