Archie Cobbs wrote:
Weldon Washburn wrote:
Thanks for getting this entered into SVN so quickly. I did a quick
check and it looks like you grabbed the most recent version. By the
way, the directory structure is still somewhat ambiguous. I keep
thinking we may want to put .../gnu.../... in the tree to distinguish
this specific adapter. The reason is that someday someone may want
to build an adapter for a non-GNU class library. It would be nice to
get this kind of directory organization sorted out now. Making mods
to the directory structure at a later date probably means hardcoded
makefiles will need to be changed.
I agree. How about "classlibadapter/trunk" -> "adapter/gnu/trunk"?
I'd keep it specific to classlib yet simple and mimic the classlib
structure with
classlibadapter/trunk/module/gnu
or something.
Now next questions... let's talk about how we want to build and
package this. It looks like basically we need to build two things,
(a) a ZIP/JAR file containing the adapter classes, and (b) a native
libarary for java.io.File.
#1. It's possible to get rid of (b) because Classpath already contains
native libraries that implement java.io.File functionality.
Classpath? The assumption here is that you don't need to have GNU
Classpath, right?
However,
because classlib has native methods in java.io.File (instead of VMFile
adapter classes) this would mean writing our own File implementation,
which would involve copying (and tracking changes to) the classlib
version, so this is probably not a good option. For now, we'll leave
it as is but that's an option that's out there. Perhaps eventually
we can get classlib to either add a VMFile class or else implement
java.io.File itself... any thoughts from classlib hackers?
#2. Should the build just produce a distribution subtree in dist/ similar
to the way classlib builds, or should it use automake, etc. and
support a "make install" target? I'd prefer the latter. That way we
can have a standard install location, e.g. we'd install under
/usr/local/harmony/adapter/gnu or something. This would faciliate
VM's that want to make it easy to use the adapter because it would
always be in a known location. If you like this idea then I can add
all the configure and automake magic, replacing the "doit.sh" scripts.
This will aid portability as well, especially because we can use
libtool for #1. The auto* stuff should be simple because we won't
be doing anything very unusual.
Whoa. Does GNU Classpath install into /usr/local/whatever?
I think you don't want to assume an install location...
#3. I think we'll need to have Classpath installed to do the build.
GNU Classpath? Why?
It's standard location is /usr/local/classpath. That way we can
compile our adapter classes with javac against all the VMFoo classes
that they will delegate to. I can add a "--with-classpath=DIR" flag
to ./configure to make this location configurable.
I'm missing something - the idea here is that GNU Classpath isn't
nearby, isn't it?
geir
Let me know what you think.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
