Hi, BTW for people who have no idea what this is actually about please read about the TARGET layer in native/target/readme.txt (GNU Classpath CVS). Autoconfiscating is explained in "The Goat Book": http://sources.redhat.com/autobook/autobook/autobook_237.html
On Fri, 2004-08-06 at 07:47, Steven Augart wrote: > If we are going to be using this stuff, we need a clear justification > for it. I would suggest that we create subdirectories for a couple of > these embedded platforms that Classpath is running on, and populate > them, so that we can see what these extreme cases actually look like. > As I understand matters, if AICAS is distributing software that uses > Classpath on such platforms, then they also must be distributing the > source code for the portability layer that Classpath requires in order > to work on those platforms. If so, then we should have that all in the > source tree, so that we can see why this is needed. Does this make > sense? (It's almost two in the morning here in New York, so it may not :)) I think this makes sense and explains why people see the TARGET layer as just an extra (obfuscated) layer of indirection. We don't have any evidence that it actually works since we don't use it ourselves. And people are looking at libgcj and kaffe and notice they do have many ports to different platforms, are mostly similar to GNU Classpath, and do use autoconf to select the implementation they need for each platform. So clearly people want to mimic that. And it is what the GNU C coding standards recommend: http://www.gnu.org/prep/standards_27.html Tom Tromey said that for libgcj they use a hybrid approach. For Posix like systems they use just one source file that uses autoconf checks to see what/how things work. For completely different systems they just compile/link against a completely different implementation source file. I think this is the way forward if we want to both keep the TARGET layer for some systems and autoconf for those systems were it works. The trick would be to come up with an good design/interface to make this work. My suggestion would be to better split the JNI functions from the actual implementation. In each native package directory we already have a java[pacakge].c file that defines common pacakge functions (native/jni/java-io/javaio.c, native/jni/java-nio/java_nio.c, native/jni/java-net/javanet.c, etc). I propose we put all real functionality in these files and make the java_[package]_[class].c JNI source files do only the JNI wrapping of these real implementation methods. So all TARGET layer or autoconfiscated stuff would be moved inside the common package functions C source files. I haven't actually tried doing this, so it might not work, but it might be a way to support both autoconfiscation and a target layer for those platforms that aren't autoconfiscatable. One additional benefit might be that if the common package functions C source files don't contain any JNI constructs that we might be able to more easily share native implementations between JNI and CNI based systems like libgcj. (This is just speculation though, I haven't investigated if we can actually do this.) Cheers, Mark
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
