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

Re: RFC: removing native libs

From: McClain Looney <mlooney_at_gmail.com>
Date: 2004-08-25 21:58:10 CEST

On Wed, 25 Aug 2004 15:43:22 -0400, Mark Phippard <markp@softlanding.com> wrote:
> I think you missed my point slightly. I do not think javahl needs to
> move. My point is that there is no reason that Subclipse cannot make its
> own builds with newer features but using the rest of the released
> Subversion code base. since javahl is a self-contained entity, and
> Subclipse in theory distributes it, there shouldn't be issues. (Famous
> last words). javahl is just not as mature as Subversion, it doesn't make
> sense for it to be on the same freeze/release schedule. I can understand
> if Subversion devs want to freeze what is going into their tarballs, but
> why should that stop Subclipse from making its own builds?

That's exactly the problem. subclipse _does_ make its own builds,
builds which may not have been built with (or without as you note
above) the same dependencies as the svn installation on the end-users
machine (this is less of an issue with win32, since that library is
statically linked). it is this mis-match which is the problem.

javahl is in no way a self contained entity (it could be considered
one on windows, sort of, for the reason mentioned above). On its own,
javahl does nothing. it just provides convenient hooks into an svn
installation's libraries.

-- 
McClain Looney
m@loonsoft.com
Received on Thu Aug 26 05:58:10 2004

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

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