On Tuesday 08 March 2011, Robert Collins wrote: > On Wed, Mar 9, 2011 at 8:39 AM, Stefano Lattarini > <stefano.lattar...@gmail.com> 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
