On 08/20/2010 10:51 PM, Ralf Wildenhues wrote:
It would be nice if I could write:
AT_CHECK([command that may fail with status 63],
[], [], [],
[AT_CHECK([test $at_status -ne 63 || exit 77])])
instead of:
AT_CHECK([command that may fail with status 63 || ]dnl
[ { test $? -eq 63&& exit 77; }],
[], [], [])
or even:
AT_CHECK([command that may fail with status 63 || ]dnl
[ { res=$?; test $res -eq 63&& exit 77; exit $res }],
[], [], [])
for mapping an exit status of 63 to a SKIP. The second variant destroys
the information of what value other than 0 or 63 the status had, the
third is even uglier, the former nicely shows the status in the verbose
log and works with Autoconf 2.59+ (at least).
Would you accept a patch to document $at_status being usable in the
RUN-IF-FAIL and RUN-IF-PASS arguments of AT_CHECK (including coverage
of course)?
Sounds good to me, unless you like my alternate idea:
If not, then we could think about using a 'stdout'-like special
value for the STATUS argument to AT_CHECK that just captures $?,
but IMVHO the status has sufficiently different semantics from
output that I hope we don't need to go this way.
If we don't want to expose $at_status, then my idea on this front is
that the user names their own variable:
AT_CHECK([command], [my_status], [], [],
[AT_CHECK([test $my_status -ne 63 || exit 77])])
The heuristic is that if the status argument is 'ignore', empty,
numeric, or non-literal (as detected by AS_LITERAL_IF, an example being
$expected) it maintains current interpretation; otherwise, it is assumed
to be a shell variable name to be assigned the exit status of the test.
However, while those alternate heuristics will allow us to avoid
exposing $at_status, it seems like a lot of complexity in the
autotest/general.m4 file, compared to just documenting a fixed name that
is available without any extra user effort.
--
Eric Blake ebl...@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
