[Top][All Lists]
[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
- Autotools GSoC ideas, Ralf Wildenhues, 2011/03/07
- Re: Autotools GSoC ideas, Stefano Lattarini, 2011/03/07
- Re: Autotools GSoC ideas, Russ Allbery, 2011/03/07
- Re: Autotools GSoC ideas, Robert Collins, 2011/03/07
- Re: Autotools GSoC ideas, Ralf Wildenhues, 2011/03/08
- Re: Autotools GSoC ideas, Stefano Lattarini, 2011/03/08
- Re: Autotools GSoC ideas, Robert Collins, 2011/03/08
- Re: Autotools GSoC ideas,
Stefano Lattarini <=
- Re: Autotools GSoC ideas, Ralf Wildenhues, 2011/03/09
- Re: Autotools GSoC ideas, Stefano Lattarini, 2011/03/09
- Re: Autotools GSoC ideas, Harlan Stenn, 2011/03/09
- Re: Autotools GSoC ideas, olafBuddenhagen, 2011/03/10
- Automake GSoC idea, Daniel Herring, 2011/03/09
- Re: Automake GSoC idea, Ralf Wildenhues, 2011/03/11