> 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
