incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: [lucy-dev] C TAP test harnesses
Date Wed, 18 May 2011 06:42:06 GMT
----- Original Message ----

> From: Marvin Humphrey <>
> To:
> Sent: Wed, May 18, 2011 1:05:49 AM
> Subject: Re: [lucy-dev] C TAP test harnesses
> On Tue, May 17, 2011 at 08:52:59PM -0700, Joe Schaefer wrote:
> > Two hours  of hacking on your pull request and I've gotten at.[ch] to the 
> >  where the apr dependence is gone and the apreq tests (tweaked by about 10  
> > all pass.  
> Nice! :)
> To bring everyone up to  speed, Joe forked at.[ch] on Github, extracting those
> files from the apreq  source tree.
> I then forked that,  applied the changes I'd been working on locally, and
> issued a pull  request.
> Joe pulled my  changes in, and then did the final hard hacking on the memory
> pool stuff to  close out the purge of the APR dependency.
> > There are some warnings  issued under maintainer mode, but I probably
> > will just ignore those and  change apreq to use this de-apr'd code instead.
> Those warnings happen  because of the way at_vsnprintf forwards all its args 
> vsnprintf, including  the format string.  Under maximally strict warnings, GCC
> wants to see  that argument tagged with an __attribute__ indicating that it's 
> format  variable so that validation can be performed at the sites where the
> function  is invoked.
> FWIW, now that we aren't using the APR IO stuff, I think we  might be able to
> adapt the test harness to print to a FILE* stream using  fprintf, instead of
> printing to a buffer using  _vsnprintf/vsnprintf.

That would undo the point of the whole report infrastructure.  The point of the
report stuff is that it allows you to direct the TAP output anywhere, to a file,
to a socket, to a bucket brigade, etc.  I want to keep that flexibility to allow
at.[ch] to be used in a client-server environment where Test::Harness drives the
client but at.[ch] runs in the server which dishes out TAP to the client.

It's easier and cheaper to use snprintf than it is to provide a stream 
abstraction with
a custom formatter.  Yeah there is a cutoff involved, but it shouldn't hamper 
output in practice.

> > > If the  apreq community were to  decide spontaneously to remove APR as a
> > > dependency  from  at.c/at.h and start publishing it as a public API with 
> > >  backwards  compatibility promises, that would be great.  But it  doesn't 
> > > sense  for apreq to accept these changes, and it  doesn't make sense for 
> > >to
> > > depend on apreq  code when it isn't in apreq's interest to tailor it to  
> > >  needs.  
> > > 
> > > If we're going to put in this much  effort making  a test harness work for

> > > we should either  fork it and own the code, or we  should be contributing 
>to a
> > >  common project with an official public API. 
> > 
> > If we can get lucy  using the code at then that 
> > be the  upstream location for both projects.
> > 
> > WDYT?
> +1 to switch  Charmonizer's test files over to this test harness, with an eye
> towards  deleting trunk/charmonizer/src/Charmonizer/Test.[ch].
> I have some IP  concerns, though.  If the project stays on Github, things are
> going to  get complicated from a code provenance standpoint.  Our Github
> commits  have not been granted to the ASF, so the ALv2 header in those files 
> no  longer accurate.  We'll need to change the copyright to use your name,  
> the guidelines in the ALv2's appendix.  We'll also need to add  LICENSE and
> NOTICE files to the Github repo, and when we pull them in to  Lucy, we'll need
> to add a clause to Lucy's NOTICE.
> I'm willing to do  the legal busywork to help ensure that all our i's are
> dotted and t's  crossed, but it might be less troublesome to have these files
> live at the ASF  somewhere.  I'm OK with your original plan to fork within
> Lucy.  I  guess I'm OK with apreq as upstream, too, if apreq really is OK with
> these  changes -- if Lucy decides that we have to fork at some future point, 
> can  just fork then.
> Also, if we want to start committing this stuff to Lucy  soon, we should start
> a topic branch in svn, since this shouldn't go into  0.1.0.

I can wait for the release.  No rush.

View raw message