Re: [GSoC Proposal] automake - Interfacing with a test protocol like TAP or subunit

[Ralf Wildenhues]

* Stefano Lattarini wrote on Sun, Mar 20, 2011 at 01:41:07PM CET:
> On Sunday 20 March 2011, Ralf Wildenhues wrote:
> > Or add a subunit parser and a quick tap2subunit perl module today
> ["perl module"? what about portability?]

awk should be sufficient, for text-mode output at least.

> > and have the best of both worlds?  (This is meant as an honest question,
> > even if it looks like a rhetoric one.)
> >
> I'd rather add a SubUnit parser only when *and if* the need arise;

But look, going the other way round, there is little change you'll ever
need to introduce an incompatible change later.

> I have to admit that, by reading more carefully the README of subunit,
> I'm intrigued by the fact that there seem to already be producers for
> C, C++, Python, Perl and the shell... Still, I'm not confartable with
> not being able to find documentation and examples that are clear enough
> to allow me to define proper goals and progress estimation.

This is fixable though, no?

As far as I can see it, so far the arguments pro TAP are/were:
- perl, rather than only python, support exists (but cf. your statement
  above),
- simplicity,
- well-definedness of the protocol.

I don't see how subunit is not well-defined, looking at the EBNF in the
README.  I understand your desire to tackle simple first, and have
something you can already overlook mostly.  But summer is long, and even
if it turns out too short: it's not necessary to finish exactly in time.

I'm a bit intrigued by the fact that subunit appears to address a few
deficiencies in TAP, and wonder whether we'd regret choosing TAP later.
That said, I guess I'm fine with a project proposal along the lines of
"try subunit support; and if that turns out too hard (e.g., for
portability issues), then fall back to TAP", if you prefer a safety net.

Cheers,
Ralf