Gregory, Today jdktools build depends on classlib and drlvm builds. Adding one more dependency between jdktools and classlib builds will lead to a cyclic dependency, which should be resolved somehow.
I think the most simple way technically is to leave launcher code in classlib component. Thanks. Ivan On 5/14/07, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
Stepan Mishura wrote: > I see the next argument for moving the launcher to jdktools - this not > a java library code indeed, it's just utility code that launches java. > But moving it to jdktools will force everybody to work with HDK. If > everybody think that this is 'right' way then I'm OK with it (I mainly > work with separate classlib and DRLVM workspaces and I find it quite > convenient) I am catching up with emails after vacations and just saw this thread. I am +0.5 to java launcher in jdktools and I think that the working process could be organized without having to build full HDK every time. Just look at how drlvm is built, it always requires to compile classlib first and no one complains about it. If someone works primary on drlvm, classlib may be compiled just once in a while and there is no big reason to rebuild it all the time when VM is built. The same could be done with jdktools. Then the sequence of building separate packages would be the following: jdktools -> classlib -> vm. Classlib build script would copy files from the deploy directory of jdktools and VM build script would copy compiled classlib to its deploy directory. Classlib developers would need to compile jdktools just once in a while (updates to the launcher are quire rare anyway) and then compile just classlib which would take java executable from jdktools. Anyway, I agree with Tim's comment that it is not the most important thing to do. > BWT, how many people use hdk build only? > > Also if we move it to jdktools we need to adjust build-and-test infra > that it requires time and efforts. But I think this in turn should > unify (i.e. simplify) the infra logic - all testing suites will depend > on hdk build only (not on classlib + drlvm (+ hdk) as currently we > have) > > Thanks, > Stepan. > >> What do you think? >> >> Tim >> > -- Gregory
