Mark Hindess wrote:
> 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 doesn't work that well. Even the SVN authors suggest people don't
use it.
> (It would of course be the only way to include SableVM given the current
> setup.)
I don't think we'd want to include the sableVM tree - we'd just use
their published artifacts...
> At least until we have ironed out any potential issues that
> will undoubtedly arise while drlvm is fixed with respect to classlib
> trunk, etc.
Right. I have to go look, but I assume that it will be a simple
property to have the classlib build into /deploy rather than
/classlib/trunk/deploy
I want to get drlvm to point at that so we can unhitch the current
drlvm-builds-classlib part of drlvm.
>
>> 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.
Yep. Good idea.
>
>> 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?
Not tight. There should be project-scope agreements on where things
live/land, but we don't want a ball of spaghetti...
>
> 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?
Exactly. This is something we discussed a long time ago - that you
should be able to into a module and work inside of it, and each module
had the freedom for build tools that made sense for it.
As for the latter, I'm not so sure we really want a free-for-all, but
it's clear that there will be "regional differences"....
>
> 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.
Right, but given the natives, there has to be agreement on things like
build target IDs or detection.
>
>
>> 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.
<shrug> :)
You can bury one in there too if you want.
geir
>
> 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]
