Re: [BIKESHEDDING PATCH] Generated tests are now just a thin layer around other tests.

[Stefano Lattarini]

At Tuesday 08 June 2010, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Tue, Jun 08, 2010 at 01:31:00AM CEST:
> > At Monday 07 June 2010, Ralf Wildenhues <address@hidden> wrote:
> 
> BTW, is gmail configurable to not quote the email address in the
> tag line?
Dunno, I usually use KMail as my mail client -- and KMail is 
configurable in that respect -- and I just reconfigured it to avoid 
quoting the email address, as you can see :-)

> > > Well, the *-p.test could set something like am_skip_defs which
> > > then would pretty much set testsrcdir and curdir only, and then
> > > unset am_skip_defs, so the defs sourcing of *.test is full,
> > > WDYT?
> >
> > Sounds reasonable.  I've amended the patch to do that.
> > Let me know what you think about it.
> 
> It would be good to know if and how you tested a patch you post. 
Since it was late-night, I just tested it in an in-srcdir build, with
TESTS=[the generated *-p.test tests]
*Bad bad bad*.
The only justification I can offer is that I considered this patch just 
a temporary patch preceding my refactoring of `tests/defs'... which
indeed is hardly a justification :-(
> 
> Anyway, this fails auxdir.test and others, because testsrcdir isn't
> absolute.
Exactly, and fairly obvious in hindsight :-(
> 
> I'm committing the following variant below, and merging to master.
> In the spirit of VPATH, the patch prefers a test in the build tree
> over one in the source tree.
I agree.
> I have tested the patch with a full distcheck, a full check in a
> VPATH and non-VPATH build, and by invoking both generated and
> non-generated tests manually (without make), from a VPATH and
> a non-VPATH build directory.
Thanks for having done what I ought to have done in the first place.

> > I also think that, in the long run, it would be advisable to
> > split `tests/defs.in' into two files:
> >
> > [CUT]
> 
> I don't see why it would be necessary to split the defs file
>  further.
Because it is indeed composed by two mostly indipendent parts:
  - definitions used the testcase, and
  - initialization/setup of the testcase
Anyway, I'll let you judge after you'll have seen my patch series on 
`tests/defs' refactoring.  Which probably I won't post soon, as I want 
to do proper testing this time.
>  OTOH, if there are bits of the gnulib test initialization
>  machinery we can profit from, that might be valuable in the
>  long run.
Very true.  But that would pertain better to another later patch 
series IMHO (as it could also end up overlapping with the gnulib).
> 
> Thanks,
> Ralf
Thanks to you for your review and your corrections.

Regards,
    Stefano