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. Thanks, Vladimir. On 5/19/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
On 5/18/06, Andrey Chernyshev <[EMAIL PROTECTED]> 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
