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

[Ralf Wildenhues]

* Stefano Lattarini wrote on Tue, Dec 14, 2010 at 11:18:32AM CET:
> On Tuesday 14 December 2010, Ralf Wildenhues wrote:
> > * Stefano Lattarini wrote on Mon, Dec 13, 2010 at 09:42:08PM CET:
> > > 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.

By itself, "this change only modifies a few files" is not a good
argument for a change.

> That said, is copy-pasteability really useful for automake tests?

Yes, for me it is.  bashdb exists only for bash, but it's often the
deficient shells that need debugging.  Batch mode is often ok except
fhat some of our tests take minutes to execute (at least on some hosts),
and that latency is just painful when you want to debug something.

> 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.

I work the other way round most of the time.

> > 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.

But why?  I don't see an inherent advantage in that, as long as the
implicit find is safe and sound.

> 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).

Are you sure most of those are not leftovers from the time where
tests/defs.in did not copy install-sh into the tree?

> 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.

Well, we have explicit testsuite coverage for that, in auxdir*.test and
others, and in your proposed other patch.

> 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.

Review coming up.

Thanks,
Ralf