On 5 June 2006 at 13:00, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>
> I'd like to discuss how we start to bring together the pieces of Harmony
> given our goal is Java SE with all the fixin's.
>
> We now have
>
> /classlib
> /jchevm
> /drlvm
>
> DRLVM and classlib work together (as I think we all like to see jchevm
> do too...)
> But given that we are a Java SE project (and not a VM project or a
> classlibrary project) I think it behooves us to start thinking how to
> organize at a higher level. We've been very focused on the classlib
> area, but that's only one part.
Perhaps we could use svn:externals rather than moving things around?
(It would of course be the only way to include SableVM given the current
setup.) At least until we have ironed out any potential issues that
will undoubtedly arise while drlvm is fixed with respect to classlib
trunk, etc.
> So, I'd like to propose something like
>
> 1) a /deploy directory in root, as a peer to /classlib and /drlvm
>
> /classlib
> /deploy
> /drlvm
Perhaps there should be a depends directory - even if the checked in
version might be quite sparse - since some of the classlib/ depends/jars
will be common to both ... i.e. at least the eclipse compiler jar.
> 2) Maybe move the launcher out from classlib to
>
> /launcher
>
> 3) Maybe create
>
> /tools
>
> where the tool work can happen?
>
> 4) Have /drlvm and /classlib build-deploy into /deploy, rather than the
> local one
>
> 3) create a top level script such that
>
> build drlvm-jdk
> or
> build jchevm-jdk
>
> does what you expect, namely build the classlib artifacts and put in
> /deploy, build the VM of choice and drop in /deploy, builds the
> toolset,etc and go from there.
It is not clear from your description how tightly integrated you
envision the jvm/classlib build to be?
I assume this script will be trivial delegating all of the work to
the subtrees? That is doing something equivalent to:
#!/bin/sh
( cd classlib; ant -f make/build.xml )
( cd ${1%-jdk}/build ; sh build.sh )
rather than trying to actually do anything clever? Specifically, it
wont do anything that prevents someone from only having to check out
classlib or drlvm rather than the whole lot?
I think that the drlvm build is always going to be substantially
more complicated - due to greater significance of platform/architecture
differences - than the classlib build and nothing is really gained by
having the same build structure for both.
> We can create our HDK snapshots from it, and drop HDKs into it for use :
>
> /deploy
> /hdk/
> /hdk1/
> /hdk2/
> /jdk
> /jre
>
> etc
I think the current layout has the jdk as a part of the hdk rather than
as a peer - much like the jre is a part of the jdk.
Regards,
Mark.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
