harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Gorr" <vvg...@gmail.com>
Subject Re: [DRLVM] build process improvement
Date Fri, 19 May 2006 04:31:38 GMT
My two cents ...

It'd be not bad to have some snapshots of HDK for the different VMs.
Depending on the preference each of us can download either of
another snapshot for the development needs.
Do you like the J9, DRLVM or Sable VM? No problems! Download it and enjoy
Maybe it makes sense to add new target for the HDK build system allowing
to replace the default VM with the preferable one.
Suppose anybody wish to run some application under other VM with the
already-downloaded HDK. You just need to run

build -Dvm.name=SableVM (just for example)

to replace the default VM.


On 5/19/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:

> On 5/18/06, Andrey Chernyshev <a.y.chernyshev@gmail.com> wrote:
> > >That should work as well, at least for class libs. Actually I was
> > >thinking of HDK containing the pre-compiled binaries for all modules,
> > >not just the ones from the class libraries. VM developers would
> > >probably want to be able to work on a single module as well, for ex.
> > >JIT or GC. They wouldn't want to compile, for example, log4cxx or APR
> > >each time they want to build VM, these binaries are also worth to be
> > >the part of HDK.
> >
> > >Either it would result into a separate HDK's containing VM and
> > >classlib modules, or we just can combine everything within a single
> > >HDK (which seems to me just simpler).
> I am  a little less clear about VM modularity requirements for
> developing/debugging etc. Sometimes bugs do cut across the functional
> pieces
> and it is nice to follow around in the debugger. So more input would be
> welcome here. But certainly compiling log4cxx etc. make no sense. Also if
> we
> intend to become compatible with a clean modular structure ( OPEN or
> whatever ), development modularity would also happen, and a composite HDK
> would be nice.
> Thanks,
> Rana

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message