Re: [RFC] Autotest: AT_TEST and XFAILs

[Akim Demaille]

 >> > I found out that there is no clear place to do initializations that
 >> > ought to be *outside* the subshell.
 >> 
 >> Could you make this clearer to me?  What kind of initialization are
 >> you referring to?  See for instance in foreign.at what are *user*
 >> initializations to me.  I'm not sure the user should have this.

 > Initializations are like setting up *features*.  Some of these
 > needs to define macros or set variables which are not propagated to
 > the top-level if they are executed inside ( ... ).

 > For example, that's where I have to set whether the test must be
 > xfailed, and AT_KEYWORDS also fails in that area.

Yes, I think we agree these are Autotest internals, and therefore they
should not be in userland.  It is by design that the user cannot
escape the sub shell, and I think it is important to preserve this
property.


 >> > In addition, I am providing an alternative interface than
 >> > AT_SETUP...AT_CLEANUP: a single macro called AT_TEST that receives
 >> > description, commands and initializations (like AC_CONFIG_FILES for
 >> > example).  The attached patch also changes the whole test suite to use
 >> > it -- it is quite mechanical to do that with "perl -i -pe".
 >> 
 >> Sorry, but I don't really like this part.  The SETUP/CLEANUP version
 >> is much clearer to me.  In addition, I don't like the small initial
 >> part being rejected to the end.  It should be the opposite IMHO.

 > Ok, I was only trying to be consistent with autoconf.  

Autoconf doesn't really have this environment-like structure.

 > I'll wait for an answer and then provide an updated patch.  In
 > particular, should I:

 > 1) use AT_TEST in the Autoconf test-suite?

I would like to avoid this part.

 > 2) invert the order of the arguments of AT_TEST even if that goes
 > against the AC_CONFIG_xxx standard?

I think so, yes.  But that's also why I think AT_TEST is not a good
thing.  If you want it, then let it be.

 > 3) set up diversions so that nothing is output in the new
 > AT_SETUP/AT_TEST argument, so that the macros used here can only
 > define other macros (like AT_KEYWORDS and AT_XFAIL_IF do)?

Why not, good idea.  In any case, this is not opened to the user, she
should not even know about this.  Which is kind of against promoting a
three argument AT_TEST actually.