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
