automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefano Lattarini
Subject: Re: [GSoC Proposal] automake - Interfacing with a test protocol like TAP or subunit
Date: Sun, 20 Mar 2011 13:41:07 +0100
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

On Sunday 20 March 2011, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Sun, Mar 20, 2011 at 11:40:39AM CET:
> > On Sunday 20 March 2011, Robert Collins wrote:
> > > On Sun, Mar 20, 2011 at 8:53 PM, Ralf Wildenhues wrote:
> > > > Are TAP and subunit compatible on their common subset?  If not, why not?
> > > 
> > > You can convert TAP to subunit, and you can convert the things TAP can
> > > represent from subunit to TAP. subunit's core is more structured than
> > > TAP, so the two protocols don't pun as each other at all.
> > >
> > If I'm not misreading the class TAP2SubUnit in python/subunit/__init__.py,
> > converting from TAP into subunit shouldn't be much difficult, even with
> > just the POSIX tools available.  This means that we could add support for
> > TAP "today", and if "tomorrow" we decide (or our users tell us) to start
> > supporting also SubUnit, we could add a SubUnit parser, and then continue
> > to support also TAP by writing a TAP->SubUnit converter and filtering TAP
> > output into it -- which would allow us to drop the TAP parser (less code
> > to maintain) without losing backward-compatibility.
> 
> Or add a subunit parser and a quick tap2subunit perl module today
["perl module"? what about portability?]
> 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; I
suspect that TAP is enough for most needs of Automake clients. Of
course, I cannot be sure this is (and always will be) really the case;
that's why I value the prospect of designing things in order to allow
an upgrade to SubUnit as painlessly and easily as possible, should the
need arise.  Maybe I should update my proposal to make clear that
having a design of this type is an explicit goal of the project ...

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.  I think
that I'll reiterate my above conclusion in the end.  Please do not take
this as a sign of disrespect towards, or a belittling of, the SubUnit
project -- this is really not the case.

Thanks,
  Stefano



reply via email to

[Prev in Thread] Current Thread [Next in Thread]