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 <addr...@elided> 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
