You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David James <st...@gmail.com> on 2004/09/02 14:24:48 UTC
[SVN RFC] Making JavaHL easier to maintain?
Subversion developers,
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'
-- We should set up a test script to build the latest version of
JavaHL and e-mail us when it doesn't pass tests
- 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.
- We should make JavaHL easier to test
-- make 'check-javahl' should automatically build the test suite if it
has not yet been built
-- make 'check-javahl' should work even if javahl has not yet been installed
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN RFC] Making JavaHL easier to maintain?
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2004-09-02 08:20-0700, Justin Erenkrantz wrote:
> --On Thursday, September 2, 2004 10:24 AM -0400 David James
> <st...@gmail.com> wrote:
> >-- 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.
If anyone of you starts implementing that, could you please drop a
line to me. I have planned to that, but so far haven't had time...
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN RFC] Making JavaHL easier to maintain?
Posted by Max Bowsher <ma...@ukf.net>.
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)
I'm quite interested in possible changes in this area. As it is a
cross-language matter, please discuss it in another thread with an
appropriate (non-java-specific) subject.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN RFC] Making JavaHL easier to maintain?
Posted by Patrick Mayweg <ma...@qint.de>.
Hi James,
David James wrote:
>Here's what Patrick wrote on Tuesday:
>
>
>>I would not considering it upgrading for javahl to use SWIG. From my
>>point of view generating the JNI header is no problem at all. I use an
>>ant script in my java ide for it. If I had to regenerate the SWIG code,
>>I always had to start a new working copy. That is much more of a problem.
>>
>>
>
>But doesn't SWIG offer benefits beyond generating the JNI headers?
>
>A quote from the SWIG documentation: http://www.swig.org/Doc1.3/Java.html
>"[Using SWIG] is different to using the 'javah' tool as SWIG will wrap
>existing C/C++ code, whereas javah takes 'native' Java function
>declarations and creates C/C++ function prototypes. SWIG wraps C/C++
>code using Java proxy classes and is very useful if you want to have
>access to large amounts of C/C++ code from Java. "
>
>The question is, how much will those capabilities benefit us?
>
>
I do not think very much for javahl. If you want to access the working
copy, file system or repository access libraries, it would be helpfull,
because you would have a much larger interface to cover. But do not see
that a target for javahl. I think that the clients for javahl will
mainly be gui's and ide plugin's.
When I started working on a java binding to subversion for svnup some
time ago, there was a very early swig binding by Alex Müller (xela). It
was not compileable and the generated classes did not look
object-oriented to me. There was a C++ binding also by Alex Müller in
the rapidsvn project, which I did like much better. Since I have written
JNI-interfaces in other projects, it was much easier and faster for me
to write a JNI-layer above the C++ binding, which I modified. For using
SWIG in that phase, I would have had to understand much more about swig
and the subversion client library. Like how to define a callback baton
in java, which will be called back by the client library or how to read
and write an apr-array.
The problem I have with SWIG lies mostly in the building system on
Windows, which did not seam to rebuild the generate code (C) after an
change in the source. This may be only a fixable problem. But for the
last time I have tried to compile any SWIG binding, it was a drag.
>Cheers,
>
>David
>
>
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problem with following renames in 1.1
Posted by Folker Schamel <sc...@spinor.com>.
Greg Hudson wrote:
> A side note: when you start a completely new thread on the dev list,
> please do not do so by replying to a message and changing the subject.
> Doing so causes your message to be incorrectly threaded in mail
> archives.
>
>
>>However, when merging changes from trunk into a branch or vice versa
>>("merge BRANCH-URL -r X:Y TRUNK-WC-PATH"), rename tracking seems to
>>fails.
>
>
> After a careful review, I think Ben's initial reply to your message
> was confused, and everything which follows from it was equally
> confused, including my own response. So, ignore all that stuff. "svn
> merge -rX:Y URL" follows renames when picking the merge anchors just
> like "svn merge -rX:Y WCPATH" follows renames.
>
> The real answer to your question is: once the merge anchors are
> picked, all merging is performed by pathname. This is part of what
> Tom Lord refers to as Subversion's "anemic merge support".
>
>
>>See the transscript below.
>
>
> Now that I review your transcript, I think it fails in exactly the way
> I would expect it to fail.
>
>
>>Merging within one tree ("merge -r X:Y WC-PATH") nicely follows
>>renames in 1.1.
>
>
> You didn't post a transcript of this succeeding. I assume you were
> merging individual files, or merging within a tree whose contents had
> experienced no renames (although the tree itself may have moved
> around).
Yes, my mistake - I only tested with an individual file.
>>Are there plans to improve this?
>
>
> Vague ones. See
> <http://svn.collab.net/repos/svn/trunk/notes/merge-tracking.txt>,
> point C. The solution to this problem may involve some fairly deep
> changes to the filesystem structure (we have to support "true
> renames"), so it may be a 2.0 improvement.
Yes, I supposed something like that.
We came accross that issue because currently we have a long living branch.
We regulary merge from trunk (having trivial scripts managing
the last merged revision).
And due to refactoring, several files are renamed in the branch.
So we encountered that issue.
[One helpful smaller change may be to not only eject the warning
"Skipped missing target", but set the nearest existing parent directoy
into a merge conflict state.
From the theoretical point of view, "Skipped missing target"
is a merge conflict.
From the pratical point of view, this avoids that you oversee
such merge failures, because svn status does not show again
the "Skipped missing target" warning.]
However, it's definitely no serious issue!
Most merging works absolutely fine. And some tweaking by hand
for these special issues is no problem at all.
Thanks for your explanations!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problem with following renames in 1.1
Posted by Greg Hudson <gh...@MIT.EDU>.
A side note: when you start a completely new thread on the dev list,
please do not do so by replying to a message and changing the subject.
Doing so causes your message to be incorrectly threaded in mail
archives.
> However, when merging changes from trunk into a branch or vice versa
> ("merge BRANCH-URL -r X:Y TRUNK-WC-PATH"), rename tracking seems to
> fails.
After a careful review, I think Ben's initial reply to your message
was confused, and everything which follows from it was equally
confused, including my own response. So, ignore all that stuff. "svn
merge -rX:Y URL" follows renames when picking the merge anchors just
like "svn merge -rX:Y WCPATH" follows renames.
The real answer to your question is: once the merge anchors are
picked, all merging is performed by pathname. This is part of what
Tom Lord refers to as Subversion's "anemic merge support".
> See the transscript below.
Now that I review your transcript, I think it fails in exactly the way
I would expect it to fail.
> Merging within one tree ("merge -r X:Y WC-PATH") nicely follows
> renames in 1.1.
You didn't post a transcript of this succeeding. I assume you were
merging individual files, or merging within a tree whose contents had
experienced no renames (although the tree itself may have moved
around).
> Are there plans to improve this?
Vague ones. See
<http://svn.collab.net/repos/svn/trunk/notes/merge-tracking.txt>,
point C. The solution to this problem may involve some fairly deep
changes to the filesystem structure (we have to support "true
renames"), so it may be a 2.0 improvement.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problem with following renames in 1.1
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sat, 2004-09-04 at 11:29, Folker Schamel wrote:
> The second from also follows renames "somehow" when using the URL@REV syntax.
> But in case of merging this "somehow" is not very useful.
>
> I suppose the reason for your decision is not because it is not useful,
> but because of its implementation complexity, right?
Actually, this might be a case of an implementation that is doing
something different that what we actually decided. Hm, watch for
replies on this.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problem with following renames in 1.1
Posted by Folker Schamel <sc...@spinor.com>.
Ben Collins-Sussman wrote:
> On Sat, 2004-09-04 at 08:19, Folker Schamel wrote:
>
>>Hello!
>>
>>Merging within one tree ("merge -r X:Y WC-PATH") nicely follows renames in 1.1.
>>
>>However, when merging changes from trunk into a branch or vice versa
>>("merge BRANCH-URL -r X:Y TRUNK-WC-PATH"),
>>rename tracking seems to fails.
>>
>>See the transscript below.
>>
>>The new 'peg' syntax "merge BRANCH-URL@REV -r X:Y PATH" seems not to help.
>>
>>I suppose this is a more fundamental problem, but neverthanless:
>>Are there plans to improve this?
>
>
> No, because we've made a deliberate UI choice here.
>
> We've decided that
>
> svn subcommand [-rX[:Y]] wcpath
>
> ..will follow renames, whereas
>
> svn subcommand [-rX[:Y]] URL
>
> ..will not follow renames.
The second from also follows renames "somehow" when using the URL@REV syntax.
But in case of merging this "somehow" is not very useful.
I suppose the reason for your decision is not because it is not useful,
but because of its implementation complexity, right?
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problem with following renames in 1.1
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2004-09-04 at 09:42, Ben Collins-Sussman wrote:
> > I suppose this is a more fundamental problem, but neverthanless:
> > Are there plans to improve this?
>
> No, because we've made a deliberate UI choice here.
Actually, I don't think we did; I think that choice was made by the
implementors, not on the mailing list. Looking at the plan in issue
#1093, URLs were supposed to peg at HEAD by default.
(How do you get to a deleted file? If you review the mailing list
conversation, I amended my plan to allow URL@REV in case 1. That
amendment didn't make it into #1093. See
http://www.contactor.se/~dast/svn/archive-2003-10/1520.shtml)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problem with following renames in 1.1
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sat, 2004-09-04 at 08:19, Folker Schamel wrote:
> Hello!
>
> Merging within one tree ("merge -r X:Y WC-PATH") nicely follows renames in 1.1.
>
> However, when merging changes from trunk into a branch or vice versa
> ("merge BRANCH-URL -r X:Y TRUNK-WC-PATH"),
> rename tracking seems to fails.
>
> See the transscript below.
>
> The new 'peg' syntax "merge BRANCH-URL@REV -r X:Y PATH" seems not to help.
>
> I suppose this is a more fundamental problem, but neverthanless:
> Are there plans to improve this?
No, because we've made a deliberate UI choice here.
We've decided that
svn subcommand [-rX[:Y]] wcpath
..will follow renames, whereas
svn subcommand [-rX[:Y]] URL
..will not follow renames.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Problem with following renames in 1.1
Posted by Folker Schamel <sc...@spinor.com>.
Hello!
Merging within one tree ("merge -r X:Y WC-PATH") nicely follows renames in 1.1.
However, when merging changes from trunk into a branch or vice versa
("merge BRANCH-URL -r X:Y TRUNK-WC-PATH"),
rename tracking seems to fails.
See the transscript below.
The new 'peg' syntax "merge BRANCH-URL@REV -r X:Y PATH" seems not to help.
I suppose this is a more fundamental problem, but neverthanless:
Are there plans to improve this?
*****
C:\temp\svntest>svnadmin --version
svnadmin, version 1.1.0 (Release Candidate 2)
compiled Aug 13 2004, 15:20:48
Copyright (C) 2000-2004 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).
C:\temp\svntest>svnadmin create --fs-type fsfs repro
C:\temp\svntest>svn mkdir file:///temp/svntest/repro/trunk -m ""
Committed revision 1.
C:\temp\svntest>svn checkout file:///temp/svntest/repro/trunk wc_trunk
Checked out revision 1.
C:\temp\svntest>echo file1 1>wc_trunk/file1.txt
C:\temp\svntest>echo file2 1>wc_trunk/file2.txt
C:\temp\svntest>echo file3 1>wc_trunk/file3.txt
C:\temp\svntest>svn add wc_trunk/file1.txt
A wc_trunk\file1.txt
C:\temp\svntest>svn add wc_trunk/file2.txt
A wc_trunk\file2.txt
C:\temp\svntest>svn add wc_trunk/file3.txt
A wc_trunk\file3.txt
C:\temp\svntest>svn commit wc_trunk -m ""
Adding wc_trunk\file1.txt
Adding wc_trunk\file2.txt
Adding wc_trunk\file3.txt
Transmitting file data ...
Committed revision 2.
C:\temp\svntest>svn copy file:///temp/svntest/repro/trunk file:///temp/svntest/r
epro/branch -m "Release"
Committed revision 3.
C:\temp\svntest>svn checkout file:///temp/svntest/repro/branch wc_branch
A wc_branch\file2.txt
A wc_branch\file3.txt
A wc_branch\file1.txt
Checked out revision 3.
C:\temp\svntest>svn move wc_trunk/file2.txt wc_trunk/file2_moved_in_trunk.txt
A wc_trunk\file2_moved_in_trunk.txt
D wc_trunk\file2.txt
C:\temp\svntest>svn commit wc_trunk -m "Refactoring"
Deleting wc_trunk\file2.txt
Adding wc_trunk\file2_moved_in_trunk.txt
Committed revision 4.
C:\temp\svntest>svn move wc_branch/file3.txt wc_branch/file3_moved_in_branch.txt
A wc_branch\file3_moved_in_branch.txt
D wc_branch\file3.txt
C:\temp\svntest>svn commit wc_branch -m "Rename in branch"
Deleting wc_branch\file3.txt
Adding wc_branch\file3_moved_in_branch.txt
Committed revision 5.
C:\temp\svntest>echo file1.new.branch (bug fix in branch) 1>wc_branch/file1.txt
C:\temp\svntest>echo file2.new.branch (bug fix in branch) 1>wc_branch/file2.txt
C:\temp\svntest>echo file3.new.branch (bug fix in branch) 1>wc_branch/file3_mov
ed_in_branch.txt
C:\temp\svntest>svn commit wc_branch -m "Bug fixes in branch"
Sending wc_branch\file1.txt
Sending wc_branch\file2.txt
Sending wc_branch\file3_moved_in_branch.txt
Transmitting file data ...
Committed revision 6.
C:\temp\svntest>svn merge file:///temp/svntest/repro/branch -r 5:6 wc_trunk
Skipped missing target: 'wc_trunk\file2.txt'
Skipped missing target: 'wc_trunk\file3_moved_in_branch.txt'
U wc_trunk\file1.txt
C:\temp\svntest>
*****
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN RFC] Making JavaHL easier to maintain?
Posted by David James <st...@gmail.com>.
Here's what Patrick wrote on Tuesday:
> I would not considering it upgrading for javahl to use SWIG. From my
> point of view generating the JNI header is no problem at all. I use an
> ant script in my java ide for it. If I had to regenerate the SWIG code,
> I always had to start a new working copy. That is much more of a problem.
But doesn't SWIG offer benefits beyond generating the JNI headers?
A quote from the SWIG documentation: http://www.swig.org/Doc1.3/Java.html
"[Using SWIG] is different to using the 'javah' tool as SWIG will wrap
existing C/C++ code, whereas javah takes 'native' Java function
declarations and creates C/C++ function prototypes. SWIG wraps C/C++
code using Java proxy classes and is very useful if you want to have
access to large amounts of C/C++ code from Java. "
The question is, how much will those capabilities benefit us?
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN RFC] Making JavaHL easier to maintain?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, September 3, 2004 1:03 PM -0400 David James <st...@gmail.com>
wrote:
> One last question: If we used SWIG as the backend to interface with
> JavaHL, how much simpler would the JavaHL code be? Do you think it's
> worth the time investment to look at that?
My hunch is that without some major work, it'd lose the OO nature of the
JavaHL code (HL == high-level as in OOish). However, you could recoup that by
having it automatically in sync with the C bindings. Daniel Rall and I, at
one point, had the SWIG Java bindings buildable; but no one has really picked
up the ball and done much with the SWIG Java interface since then. (They may
not even build at the moment; we could try to get it building again.)
I think Patrick might be able to give a clearer answer to this. I know he had
reasons why he didn't want to use SWIG in the first place. Daniel and I
focused most of our efforts on the build system in the hopes that someone
would pick it up if it was buildable. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN RFC] Making JavaHL easier to maintain?
Posted by David James <st...@gmail.com>.
> I'm also not sure what you mean by the JNI headers we're bundling right now.
> The only header files we're including now are the ones required for the C++
> library.
Ah, okay. I was wrong. Thanks for all of your patience, Justin :)
One last question: If we used SWIG as the backend to interface with
JavaHL, how much simpler would the JavaHL code be? Do you think it's
worth the time investment to look at that?
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN RFC] Making JavaHL easier to maintain?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, September 3, 2004 12:31 PM -0400 David James <st...@gmail.com>
wrote:
>> 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?
> I now think that we should stop bundling the JNI headers and instead
> add "javahl-javah" as a prerequisite for "javahl" in the Makefile.
It already is a prereq for javahl:
javahl: javahl-java javahl-javah javahl-lib javahl-tests
I'm also not sure what you mean by the JNI headers we're bundling right now.
The only header files we're including now are the ones required for the C++
library. Or, am I misunderstanding? -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN RFC] Making JavaHL easier to maintain?
Posted by David James <st...@gmail.com>.
> 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 [...]
Ah, great! Well then, there's no need to bundle Ant -- we can do it
all with make. Thanks for your help!
> 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?
I now think that we should stop bundling the JNI headers and instead
add "javahl-javah" as a prerequisite for "javahl" in the Makefile.
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN RFC] Making JavaHL easier to maintain?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, September 3, 2004 9:40 AM -0400 David James <st...@gmail.com>
wrote:
> 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
Re: [SVN RFC] Making JavaHL easier to maintain?
Posted by David James <st...@gmail.com>.
> I'd strongly prefer not to introduce any more developer dependencies than we
> already have without an extremely clear justification. At this point, the
> Java compilation is fairly straightforward, so I'm not seeing the benefit of
> using Ant here.
>
> So, what problem would JavaHL migrating to Ant solve? And, can 'make' be
> taught the right things instead? -- justin
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)
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)
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.
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN RFC] Making JavaHL easier to maintain?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, September 3, 2004 8:57 AM +0200 Patrick Mayweg <ma...@qint.de>
wrote:
> I only want to compile the java sources with ant. Not compiling the c++
> sources or even linking them.
I'd strongly prefer not to introduce any more developer dependencies than we
already have without an extremely clear justification. At this point, the
Java compilation is fairly straightforward, so I'm not seeing the benefit of
using Ant here.
So, what problem would JavaHL migrating to Ant solve? And, can 'make' be
taught the right things instead? -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN RFC] Making JavaHL easier to maintain?
Posted by Patrick Mayweg <ma...@qint.de>.
Hi Justin,
Justin Erenkrantz wrote:
> --On Friday, September 3, 2004 1:36 AM -0400 David James
> <st...@gmail.com> wrote:
>
>> How about we bundle the Ant jar with Subversion?
>
>
> Eek. I certainly don't believe we *need* ant at all. (The latest
> release of ant is about a 1MB JAR file.)
>
>> Sure -- if we're already bundling Ant, we could use it for building
>> JavaHL. Does your Ant makefile work for building JavaHL?
>
>
> Ant wouldn't have the correct logic to build the JNI libraries in a
> portable manner. For all the warts of libtool, it generally knows how
> to build shared libraries correctly on most platforms. I don't care
> to have us duplicate that logic in an XML file. Ouch. -- justin
I only want to compile the java sources with ant. Not compiling the c++
sources or even linking them.
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN RFC] Making JavaHL easier to maintain?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, September 3, 2004 1:36 AM -0400 David James <st...@gmail.com>
wrote:
> How about we bundle the Ant jar with Subversion?
Eek. I certainly don't believe we *need* ant at all. (The latest release of
ant is about a 1MB JAR file.)
> Sure -- if we're already bundling Ant, we could use it for building
> JavaHL. Does your Ant makefile work for building JavaHL?
Ant wouldn't have the correct logic to build the JNI libraries in a portable
manner. For all the warts of libtool, it generally knows how to build shared
libraries correctly on most platforms. I don't care to have us duplicate that
logic in an XML file. Ouch. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN RFC] Making JavaHL easier to maintain?
Posted by David James <st...@gmail.com>.
> I am not sure about that. That could lead to quiet a number of ant's on
> the systems. And there may be license issues to consider.
It's just a local version of Ant to use during our build -- we won't
install it with Subversion.
There's no license issues with Ant because Ant is bundled under the
Apache License. We're already bundling APR, and APR also uses the
Apache License.
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN RFC] Making JavaHL easier to maintain?
Posted by Patrick Mayweg <ma...@qint.de>.
Hi David,
David James wrote:
>>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?
>>
>>
>Sure. I'm setting it up on Red Hat Linux 7.1.
>
>
>
>>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.
>>
>>
>How about we bundle the Ant jar with Subversion?
>
I am not sure about that. That could lead to quiet a number of ant's on
the systems. And there may be license issues to consider.
>
>
>
>>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.
>>
>>
>Sure -- if we're already bundling Ant, we could use it for building
>JavaHL. Does your Ant makefile work for building JavaHL?
>
>
Not yet. But that´s simple. I think I will commit a new version tonight.
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN RFC] Making JavaHL easier to maintain?
Posted by David James <st...@gmail.com>.
> 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?
Sure. I'm setting it up on Red Hat Linux 7.1.
>
> 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.
How about we bundle the Ant jar with Subversion?
> 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.
Sure -- if we're already bundling Ant, we could use it for building
JavaHL. Does your Ant makefile work for building JavaHL?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN RFC] Making JavaHL easier to maintain?
Posted by Patrick Mayweg <ma...@qint.de>.
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
Re: [SVN RFC] Making JavaHL easier to maintain?
Posted by David James <st...@gmail.com>.
> > -- 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.
> > - 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
Re: [SVN RFC] Making JavaHL easier to maintain?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, September 2, 2004 10:24 AM -0400 David James <st...@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