harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Archie Cobbs <arc...@dellroad.org>
Subject Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods
Date Tue, 02 May 2006 01:29:07 GMT
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"?

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. 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.

#3. I think we'll need to have Classpath installed to do the build.
     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.

Let me know what you think.


Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message