Justin Erenkrantz wrote:
> --On Friday, March 12, 2004 11:23 AM -0600 kfogel@collab.net wrote:
>
>> I'm wondering, is there some way we can make it easier to catch such
>> problems earlier? If it would help, we could make it part of the
>> release process to send out a reminder to try building the bindings on
>> the soon-to-be-released branch. If we did that the moment we set the
>> date for a release, then bindings fixes could come in much sooner.
>
> Sure. Allow everyone to build it and provide regression tests for the
> bindings. This'll allow the RM to know that their bindings aren't duds
> (i.e. as part of the 'make check' process).
>
> dlr and I are trying to get #1 solved first (get the Java bindings to
> build at all), then we can work on #2. But, this is a slow process as,
> well, we're doing this in the limited amount of time we have. (We're
> trying to schedule a time when the both of us can coordinate in
> real-time on this.)
Minutes later I sent a mail indicating that the Java bindings do build now! The
installation build target completes successfully, but doesn't produce a usable
system.
> We have a plan, and we're getting there. Note that the patch you
> committed is rendered moot with the integrated javahl build system.
> Problems like that go away. My plan is that we can get the build
> systems resolved by the time we go to 1.1. Full-on regression testing
> will probably take until 1.2. -- justin
Speaking of tests, in I what little time I have to spend developing the
SWIG/Java bindings, I will be developing simple automated tests in conjunction.
I was wondering on how to tie these tests in with the existing build and test
system. Should they be run as part of the main test suite when --enable-swig is
true for the Java bindings? I need to work this out before starting any real
development, as I lack extra time to repeatedly invest in working on the actual
build logic -- that time is better spent getting the bindings application code
to work.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 12 20:36:33 2004