----- Original Message ---- > From: Marvin Humphrey <[email protected]> > To: [email protected] > 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 >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. > > https://github.com/joesuf4/at > > I then forked that, applied the changes I'd been working on locally, and > issued a pull request. > > https://github.com/creamygoodness/at > > 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.
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 the 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 >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 http://github.com/joesuf4/at then > > that >can > > 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 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. I can wait for the release. No rush.
