classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(no subject)


From: cbj
Subject: (no subject)
Date: Wed, 3 Jan 2001 18:36:14 -0500

Sender: address@hidden
To: Bryce McKinlay <address@hidden>
Cc: address@hidden,  address@hidden
Subject: Re: (no subject)
References: <address@hidden> <address@hidden>
From: Brian Jones <address@hidden>
Date: 03 Jan 2001 18:36:14 -0500
In-Reply-To: Bryce McKinlay's message of "Thu, 04 Jan 2001 11:43:50 +1300"
Message-ID: <address@hidden>
Lines: 22
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Bryce McKinlay <address@hidden> writes:

> address@hidden wrote:
> 
> > Further, I would rather that someone merge the implementations between
> > gcj and Classpath without regard to not having this or that
> > implemented in JNI (just CNI) and someone else can fill in JNI methods
> > as they come up.
> 
> Even if it means breaking Classpath code that is currently working?
> Perhaps it would be better to put the merged version in the gcj tree
> only for now, and someone can copy them over to classpath when they
> feel motivated to write JNI versions of the native bits?

Breaking the build is indeed annoying.  What you suggest sounds
reasonable, but we need a list of the merged files already in gcj but
not in classpath.  Should we look at the gcj ChangeLog for this bit of
information... the gcj team would have to explicitly say X has been
resolved against classpath but has not been merged, yes?  

-- 
Brian Jones <address@hidden>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]