automake
[Top][All Lists]
Advanced

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

Re: Autotools GSoC ideas


From: Stefano Lattarini
Subject: Re: Autotools GSoC ideas
Date: Tue, 8 Mar 2011 22:50:47 +0100
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

On Tuesday 08 March 2011, Robert Collins wrote:
> On Wed, Mar 9, 2011 at 8:39 AM, Stefano Lattarini
> <address@hidden> wrote:
> > I don't know how the GSoC proposals are evaluated, but if reviewers tend
> > to prefer more precise goals, extending the proposal in this way might
> > not be a smart move.  Maybe something like the following would be better?
> >
> >  ``Interfacing with the Test Anything Protocol (TAP).  If possible, try
> >   to write an implementation that will allow future extensions to
> >   similar but more advanced advanced protocols (e.g., subunit, which
> >   is similar to TAP but slightly more structured, capable of handling
> >   binary attachments, and so on).''
> 
> You could - or you could just write to the most capable and let folk
> insert a filter (e.g. tap2subunit, included in the subunit package) if
> they are using a different protocol themselves.
>
This seems a good approach from a design point of view; unfortunately, the
existing filters in the `subunit' distribution all require python, which
hampers portability in a way unacceptable for automake.  So your approach
would require a re-writing of those tools (or at least some of them) in
more portable languages (e.g. awk or shell scripting) before they could be
integrated in automake.

> There are a whole bunch of such protocols with varying capabilities
> around - tap, subunit, junit's xml format, glib's xml format, at least
> one json based format...
>
But since we need to start somewhere, I'd say we start with TAP, which
seems simple enough to parse portably (using only line-based tools that
are typical of unix environments), and which, in many situations, is
already a definite improvement over the existing "simple-tests protocol"
automake currently uses (to give credit where credit's due, the latter
has improved dramatically in the latest versions, and IMNSHO now offers
a truly pleasant user experience -- but if that could be improved even
more, I'm all for it).

Regards,
  Stefano



reply via email to

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