[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: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2004-09-03 18:21:50 CEST

--On Friday, September 3, 2004 9:40 AM -0400 David James <staple@gmail.com>

> Patrick has written a script (in Ant) to autogenerate the JNI headers
> and (optionally) to compile the Java sources. So if we use Ant, we'll
> solve two problems:
> 1. Currently, the Java dependencies aren't set up correctly (This is
> easy to fix, but still requires some work)

As you said, this is relatively easy to fix.

> 2. We'll autogenerate the JNI headers, so they don't need to be
> constantly updated in the subversion repository whenever there's an
> API change. (This is a very hard task to accomplish using Make)

Wait a sec. What exactly do you mean by 'autogenerate the JNI headers' - we
already do that. The 'javahl-javah' make target is already calling 'javah' on
the same argument list as Ant (looking at the build.xml we have already in the
repository). In fact, the 'javahl-javah' target is more complete than Ant as
that class list is dynamically generated not hard-coded as it is in Ant.

So, I'm not sure what task you are trying to achieve here. Can you please
expand specifically on what you think we should be doing?

> If we include the Ant JAR with Subversion, using Ant doesn't add a
> dependency -- we're just calling our local version of Ant. It's not
> unusual to bundle things with Subversion -- notice that we're already
> bundling Neon and libtool.

libtool and neon are fairly small in comparison to Ant and both provide a lot
of functionality in return. I'm not yet seeing the justification for a 1MB
extra source download for something we could achieve with make. -- justin

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 3 18:22:02 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.