harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stepan Mishura" <stepan.mish...@gmail.com>
Subject Re: [tools][launcher] Where should the launcher code reside?
Date Tue, 15 May 2007 03:25:56 GMT
On 5/14/07, Gregory Shimansky wrote:
> Ivan Popov wrote:
> > 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 for pointing this. I didn't know that jdktools depends on
> classlib and drlvm. To break the cycle perhaps we'll have to move some
> common stuff to common_resources.
>

As far as I remember common_resources 'subproject' was created for
dealing with external dependencies that common for classlib, drlvm,
jdktools. So from my POV it is not the right place for launcher.

-Stepan.

> > On 5/14/07, Gregory Shimansky <gshimansky@apache.org> 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
> --
> Gregory

Mime
View raw message