Tom Tromey [EMAIL PROTECTED] writes:
Brian I think as far as CVS goes we could set it up so that the ,v
Brian files from Classpath's tree get copied over to cygnus regularly
Brian in the libjava directory of libgcj.
No, we can't do that. This approach fails to consider branches in our
Brian I think as far as CVS goes we could set it up so that the ,v
Brian files from Classpath's tree get copied over to cygnus regularly
Brian in the libjava directory of libgcj.
No, we can't do that. This approach fails to consider branches in our
repository. It also fails if anybody ever
On Dec 19, 1999, Brian Jones [EMAIL PROTECTED] wrote:
I can't build libgcj at the moment, missing rpath on my system. I
also can't find a reference to rpath on Debian's package search
engine.
I bet this is just a missing backslash somewhere in the Makefile.
--
Alexandre Oliva
On Dec 16, Stuart Ballard wrote:
Paul Fisher wrote:
The JNI/CNI issue could be solved post agreeing to cooperate. I don't
see the JNI/CNI issue to be terribly important. gcj aims to support
JNI, but that code needs to be completed. I personally find CNI to be
extremely elegant (about
Jochen wrote:
I think we should only use JNI in classpath. We don't need another
abstraction layer, since JNI is abstract enough.
One of the goals of the Classpath project is to remain VM-neutral.
Using JNI supports this goal.
Libgcj, on the other hand, was written solely in support of the
Anthony Green [EMAIL PROTECTED] writes:
2. Merge the projects into a single source base in support of all of
our combined goals.
[2] is also possible. It will require developing a new build system
in which we can specify JNI or CNI bindings. In libgcj, we currently
put CNI code in
Anthony Green wrote:
One of the goals of the Classpath project is to remain VM-neutral.
Using JNI supports this goal.
Libgcj, on the other hand, was written solely in support of the gcj
execution environment. Using CNI is important for performance
reasons.
That's why I brought up the
Stuart Ballard wrote:
One of the goals of the Classpath project is to remain VM-neutral.
Using JNI supports this goal.
Doesn't this settle the issue then?
Or, we could implement one in terms of the other, or implement an
abstraction layer over the top that allowed C code to use whichever
8 matches
Mail list logo