lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: [lucy-dev] C TAP test harnesses
Date Wed, 18 May 2011 05:05:49 GMT
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 point
> where the apr dependence is gone and the apreq tests (tweaked by about 10 LOC)
> 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 to
vsnprintf, including the format string.  Under maximally strict warnings, GCC
wants to see that argument tagged with an __attribute__ indicating that it's a
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.

> > 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 full
> > backwards  compatibility promises, that would be great.  But it doesn't make
> > sense  for apreq to accept these changes, and it doesn't make sense for Lucy  
> >to
> > depend on apreq code when it isn't in apreq's interest to tailor it to  Lucy's
> > needs.  
> > 
> > If we're going to put in this much effort making  a test harness work for us,
> > 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 can
> be the upstream location for both projects.

+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 is
no longer accurate.  We'll need to change the copyright to use your name, per
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, we
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.

Marvin Humphrey

View raw message