AS_IF breakage (was: AC_TRY_COMPILE() annoyances with 2.63b)

[Eric Blake]

Eric Blake <ebb9 <at> byu.net> writes:

> Sorry for committing before the testsuite completed.  It turns out that
> this introduced a regression in 'make check TESTSUITEFLAGS="-k
> AC_RUN_IFELSE"', due to the following:
> 
> $ if false; then :; else echo $?; fi
> 1

In the process of trying to work around this, I discovered a bug in zsh 4.3.9:

$ zsh -c 'emulate sh; false; $empty; echo $?'
1

All other shells that I tried obey this POSIX rule [1]:

"If there is no command name,... the command shall complete with a zero exit 
status."

and correctly echo 0.

[1] 
http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_0
9_01

> But adding the : after the else, we have effectively made it impossible
> for the user to grab $? after the if condition, so I'll have to rethink
> this patch.

Various things I've tried - the idea here is to replace 'echo $?' with anything 
else the user might have supplied, including an m4 macro that expands to the 
empty string:

if false; then :; else $empty
echo $?; fi

This fails to preserve status, except on zsh where it triggered the shell bug 
mentioned above.


if false; then :; else
$empty echo $?; fi

For simple commands, this works fine.  But it inhibits recognition of the word 
after $empty as a keyword, causing syntax errors if you try to insert a 
compound command instead of 'echo $?'.



nop() { return; }
if false; then :; else nop
echo $?; fi

preserves $? on compliant shells.  But this fails on older ash and on Solaris 
ksh (but surprisingly passed on Solaris /bin/sh).  A slight tweak:

nop() { return $?; }
if false; then :; else nop
echo $?; fi

and Solaris ksh is happy, but ash still fails.

nop() { return $1; }
if false; then :; else nop $?
echo $?; fi

correctly preserves the exit status for all shells I have access to, but it 
sure adds a lot of characters.  On the other hand, the definition for that nop 
matches as_fn_set_status, which m4sh is already using.


So, would we rather write:

m4_define([_AS_IF_ELSE],
[m4_ifnblank([$1],
[else as_fn_set_status $?
  $1
])])

or revert today's patch to the simpler

m4_define([_AS_IF_ELSE],
[m4_ifnblank([$1],
[else
  $1
])])

which puts the burden back on the user, where calling:

AS_IF([false], [], [AC_REQUIRE(...)])

causes a syntax error.

If I could get AC_REQUIRE to play nicely with m4_expand, then that would be the 
solution - pre-expand the user's text, at which point we then know for certain 
whether the expansion is empty.  But right now, I don't know how to pull that 
trick off.

-- 
Eric Blake