Re: [PATCH] introduce AT_SKIP_IF and AT_FAIL_IF

[Paolo Bonzini]

> Also, the current semantics of AT_XFAIL_IF are that all conditions are
> collected up front, and then run before any of the group even if they were
> written after the tests.  I like the semantics of these two macros better
> (tests run prior to this point are run as-is, so you can rely on a
> 'skipped' test meaning that everything before the skip is still good).
> Part of me thinks it might be nice to change AT_XFAIL_IF to use similar
> semantics, but then the other part worries about backwards compatibility

I think it's not trivial either to change it.  I doubt it makes a difference in
practice, there are not many Autotest users and even fewer AT_XFAIL_IF
users.

> I like the idea.  But there were enough nits, so let's see a revised patch
> before you push anything.

I attach just the delta since the patch is relatively big.

>> +# AT_FAIL_IF(SHELL-EXPRESSION)
>> +# -----------------------------
>> +# Set up the test to be expected to fail if SHELL-EXPRESSION evaluates to
>> +# true (exitcode = 0).
>>
>> +# AT_SKIP_IF(SHELL-EXPRESSION)
>> +# -----------------------------
>> +# Set up the test to be expected to fail if SHELL-EXPRESSION evaluates to
>> +# true (exitcode = 0).

Clear pastos.

>> +m4_ifval([$1], [$1 && ])at_fn_check_skip $2])# _AT_CHECK_EXIT
>
> _AT_CHECK runs $1 in a subshell (protecting against setting stray
> environment variables); should we do the same here?  Do we want the
> following, or is it just overkill given that we documented that the
> condition should not have any output?
>
> m4_ifval([$1], [($1) >/dev/null 2&>1 && ])at_fn_check_skip...

I added the subshell, but not the redirections.

> at_fn_check_skip takes two arguments, not one (what LINE do you plan on
> using for AT_FAIL_IF)?

AT_LINE works.

> Nice use of the new idiom,
> as well as avoiding it where stderr output might be useful in the log.

Thanks.

Paolo

autoconf-skip-fail-nits.patch
Description: Binary data