Re: [SVN RFC] Making JavaHL easier to maintain?

--On Thursday, September 2, 2004 10:24 AM -0400 David James <staple@gmail.com>
wrote:

> I'm planning to work on making JavaHL easier to maintain. What would
> you like me to work on?
>
> Here are some of my ideas (can you give me some feedback?):
> - JavaHL should be integrated into the standard build process
> -- If --enable-javahl is set, JavaHL should be built, tested, and
> installed when you call 'make', 'make check', and 'make install'

If we wanted to do that, it'd be fairly trivial to change, but so far we don't
do that for the Perl or Python bindings either. So, JavaHL is currently
consistent with all of the other bindings.

> -- We should set up a test script to build the latest version of
> JavaHL and e-mail us when it doesn't pass tests

Getting a machine to run 'make check-javahl' and sending email to
svn-breakage@ would be a good start.

> - We should autogenerate the JNI headers for JavaHL instead of
> updating them manually
> -- Patrick Mayweg has an Ant script to autogenerate the JNI headers.
> We should call this script when users make javahl.

I think this is probably a good place to focus efforts on. I also wouldn't
assume that end-users have Ant available.

> - We should make JavaHL easier to test
> -- make 'check-javahl' should automatically build the test suite if it
> has not yet been built

The problem here is that the JavaHL make system needs to learn dependencies.
That is, don't build the *.class files if they already exist. (I think the
dependencies for the C code is okay, but not for the Java files.) The current
make system doesn't know how to do that. (The Python bindings aren't
completely correct in this respect, either as they always rebuild the
libraries.)

It may just be as simple as adding in some dependency rules for %.class:
%.java.

> -- make 'check-javahl' should work even if javahl has not yet been installed

Perhaps, but I think you'll run into oddities about how libtool mucks with the
shared libraries before installation and trying to teach Java that specific
convention. -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 2 17:20:54 2004