[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: David James <staple_at_gmail.com>
Date: 2004-09-02 20:32:45 CEST

> > -- 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.
The typical process for building a UNIX program is:
 ./configure [with some options]
 make install

If the user asks configure to enable JavaHL (or the Perl or Python
bindings), then I would expect "make" and "make install" to build and
install the bindings. So I'm in favour of setting up "make" and "make
install" to do that for all of the bindings, including JavaHL. Does
that sound like a good idea? (If anyone else also has an opinion on
this, feel free to jump in)

> Getting a machine to run 'make check-javahl' and sending email to
> svn-breakage@ would be a good start.
Ok, I'll set this up.

> > - 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.
I've added this idea to this issue tracker as issue 2038.

> > - 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.)
I've added this to the issue tracker as issue 2039.

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.