Hi David,
David James wrote:
>>>-- 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
> 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.
>
Could you put directly on the cc of that. I do not want to read
svn-breakage in full, only the javahl stuff. On what platform do you
plan to set it 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.
>
The reason why I did not use that before was, I do not want to force the
user to install ant. I think there will be to different kind of people
to compile javahl.
1. People who just want to use it for like svn4idea or subclipse. They
will seldom have to rebuild javahl. I think they can live with the
current build system.
2. People who want maintain javahl. For them having ant should not a big
deal.
>
>
>
>>>- 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.)
>>
You should be able to it without an installation, if you specify
java.class.path and java.library.path correctly. Using ant could be the
solution for the dependency problem.
>>
>>
>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
>
>
>
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 3 07:10:55 2004