Re: [PATCH 0/2] Tests initialization: put default definition of AC_CONFIG_AUX_DIR in the pre-populated configure.in.

[Stefano Lattarini]

On Tuesday 14 December 2010, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Mon, Dec 13, 2010 at 09:42:08PM CET:
> > On Monday 13 December 2010, Ralf Wildenhues wrote:
> > > I'm undecided on this one.  On the one hand, the safety increase is a
> > > plus, but on the other hand, the tests become less readable, if only
> > > because it is less obvious what is going on.  If you don't remember,
> > > you have to start reading the generated configure.in file after
> > > rerunning the test with keep_testdirs=:.
> > > 
> > > Hmm.  There is precedent with the 'parallel_tests' settings,
> > >
> > Speaking against my own "interest" (i.e. seeing the patch applied),
> > I must say that the 'parallel_tests' setting was more "compelled",
> > since it was needed for having generated tests that are just a thin
> > layer around their sister tests.
> > 
> > > but even that looks unobvious to me, just like those actions
> > > triggered by a 'required' setting other than "is this test
> > > run or not".
> > > 
> > Maybe we could solve this problem with a new `write_configure'
> > subroutine in tests/defs, so that we could end up having e.g.:
> 
> That's better because of this:
> 
> > I like this idea because, as a general rule, I think that "explicit
> > is better than implicit".  Also, the `write_configure' subroutine might
> > be easily extended in the future, to provide additional goodies.  WDYT?
> 
> but it still has the same problems with respect to the test being
> obvious and copy-pasteable.
>
That shouldn't be a big problem IMVHO, since the grat majority of the
tests are expected to stick with the default AC_CONFIG_AUX_DIR anyway.

That said, is copy-pasteability really useful for automake tests?
Isn't it easier to just operate "batch-mode" here, i.e. copy the content
of a test to be debugged and/or inspected into a new temporary test
script, tweak it as needed, and then run it?  I've found myself doing
that more than once, and it was almost always faster and cleaner than
meddling with the generated directory `testcase.dir' by hand.

> Again: what is the risk here that this change is trying to avoid
> (which presumably was the reason for it in the first place)?
>
The real reason about the patch was that I thought being explicit
about the build auxdir was better than letting automake found it
implicitly in almost every test.  That this could be a good idea
was "confirmed" bythe fact that some tests explicitly put a call
like:
  AC_CONFIG_AUX_DIR([.])
in the generated configure.in, with a comment reading something
like "prevent automake from looking into .. and ../.. when trying
to copy required files" (or something of this ilk).
Also, many automake-using packages specify their build auxdir
*explicitly* in configure.ac (with a call to AC_CONFIG_AUX_DIR),
so being similarly explicit in our testsuite too would make it
more "representative" of real-wolrd usages.

That said, I'm not really pushing hard for the [PATCH 1/2], but
even if that's rejected, I *really* think we should apply
[PATCH 2/2] (with proper amendings) anyway, as it genuinely
increases coverage.

Thanks,
   Stefano