* Robert Collins wrote on Sun, Mar 20, 2011 at 10:03:10AM CET: > On Sun, Mar 20, 2011 at 8:53 PM, Ralf Wildenhues wrote: > > * Robert Collins wrote on Sun, Mar 20, 2011 at 05:10:16AM CET: > >> TAP is an extremely simple protocol, and the extensions to it to > >> support things like not needing to maintain the count of tests, > >> additional debug data and so on are pretty rudimentary. subunit, which > >> I've mentioned before was written after TAP, to solve similar problems > >> and address the issues in TAP itself. > > > > 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.
Are there existing converters? > >> Unlike TAP subunit supports attachments (binary and text) to tests, > > > > Handling of binary data may end up being quite tricky within a > > restricted Posix environment with only a few tools available. > > What if a consumer cannot handle them? Is there possibility > > for graceful fallback? > > I didn't think posix had 7 bit limits? Well, I meant generally handling binary data with shell tools only. Analyzing binary data with portable shell tools can be tricky. > Anyhow, there is a baseline > profile which assumes just a single description of the error in a test > - it uses \r] to delimit a traceback. Alternatively, a C parser - on > my 'sometime' TODO list - will probably clock in small enough to > bundle for projects very low in the dependency stack. It would be nice if autotools could cope without compiled code. That leads to complications when $CC is a cross-compiler. But I see in the link that seemingly a shell consumer already exists. So maybe my worries are moot. Is there any way we can measure existing usage of TAP or subunit that doesn't rely on hearsay? Thanks, Ralf
