harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [build] ant utility target to copy working_vm to working_classlib
Date Mon, 18 Feb 2008 07:08:35 GMT
2008/2/18, Nathan Beyer <nbeyer@gmail.com>:
> I think you misunderstood me. I want to facilitate classlib
> development, not tie it to the federated build or require the
> federated build to be run constantly. I just want to get to a point
> where I can run classlib tests and rebuilds with drlvm. Have you tried
> to do this from a completely clean state recently? As I inferred in
> another reply, it's a bit mysterious. I'm having an excruciating time
> trying to do this in the past week on a Window and a Linux system.
> Here's what I tried -
> * Download HDK for last milestone, extracted it into 'deploy' folder
> of classlib, ran a build and test. On both Windows and Linux this
> failed with an "unable to load harmonyvm" error for every test.

This is the infamous hythr problem: classlib's build overwrites actual
hythr with it's own binary and drlvm cannot start anymore. This
problem will block nearly all sensible scenarios for classlib
developers. Easy to hack around in build scripts, but I wonder if we
have any aspiration to fix the rootcause...

> * Ran a full federated build, copied 'working_vm/deploy' to
> 'working_classlib/deploy' and ran 'ant test' in 'working_classlib';
> this failed with a build error about missing file
> 'deploy/build/defines.mak'. Shouldn't you be able to run the classlib
> tests after a federated build?

That's strange, did you _replace_ the deploy dir actually? DRLVM does
not use make thus does not include those defines into it's build, but
surely classlib copies them to the place during federated build.

> * Same result when I copied
> 'working_vm\build\windows_x86_msvc_release' to
> 'working_classlib/deploy'.

The 'working_vm\deploy' is a verbatim copy of
'working_vm\build\windows_x86_msvc_release', just for federated build

> * I tried doing a 'ant rebuild test' for the 'working_classlib' in
> both of the previous, but this blew up with a different error that I
> don't recall at the moment.
> * The scenario that DID work was after a federated build, copy the
> 'trunk/hdk' to the 'working_classlib/deploy' and then running 'ant
> test' in the 'working_classlib' folder.
> Now, I'm sure all of the scenarios are weird or unusual, but there's
> no documentation on the best thing to do. What is the prescribed
> working model for getting a working classlib folder that I can do
> rebuilds and tests?
I guess there is only 1 documented way [1], using HDK as:
$ ant -Dhy.hdk=<path> test
I did not test if it ever works, my bet it doesn't on clean workspace
(but probably works rigth after federated build). I recall there is
weird dependency, "test" target relies on test support artifacts
collected by target "build" and not all such artifacts are included to

> Same for a working VM.
Nope, working_vm should not have aforementioned problems. Opposite to
classlib, which has no mandatory dependencies to other modules and has
backup engines (j9 and jrockit at least), the mainstream workflow for
DRLVM requires importing  classlib artifacts to comprise workable JRE.
Both federated build and hand-built classlib are suitable for such
scenario. Moreover it is possible to test 3rd party JRE within a clean
workspace without extra compexities, e.g.:
$ ant smoke.test kernel.test -Dtest.jre.home=... -Dtest.mode=jit,srv

> The concept of the federated build is wonderful and all, but the
> current implementation is less than desired. We should be able to run
> a federated build and then, without additional manual steps, run
> 'working_vm' tests, run 'working_jdktools' tests and run
> 'working_classlib' tests.

This sound a bit like "we should be able to run all tests from
federated build directly", which I tend to agree - top-level "test"
target looks feasible :)
As for classlib-centric scenarios, there are 2 major blockers IMO:
1) Aforementioned hythr conflict;
2) "test" target should be workable on a clean workspace (at least if
provided with HDK location).
After these are addressed, either manual copying or automated
back-deployment through federated scipts should be enough.


> -Nathan
> On Feb 17, 2008 4:24 AM, Alexey Petrenko <alexey.a.petrenko@gmail.com> wrote:
> > Current federated build is not suited for every day work. Because it
> > makes only clean builds and this takes lots of time.
> >
> > So we should keep possibility to build class library, vm and selected
> > class library module alone.
> >
> > SY, Alexey
> >
> > 2008/2/17, Alexei Fedotov <alexei.fedotov@gmail.com>:
> >
> > > Nathan, all,
> > > Copying class library artifacts to the working_vm/ directory is a
> > > legacy of two component system, isn't it? Now, when we have several
> > > (three, and will have more) upper level components, it looks
> > > reasonable to collect the build artifacts at the same upper level. Why
> > > should not we assemble the build in the target/ dir? May be one should
> > > add several target directories for different build configurations. I
> > > believe that the artifact location should not affect class library
> > > development, we just need to move deploy directories to a common
> > > place.
> > >
> > > What do you think?
> > >
> > > On Feb 16, 2008 11:58 PM, Nathan Beyer <ndbeyer@apache.org> wrote:
> > > > I was thinking that we could use a utility target in the top-level
> > > > build script that copied the HDK artifacts from the working_vm to the
> > > > working_classlib, but I'm still catching up with the new DRLVM build.
> > > > Would copying the 'working_vm/deploy' to the 'working_classlib/deploy'
> > > > be sufficient?
> > > >
> > > > The use for this would be to facilitate class library development, so
> > > > I want to be able to run the top-level build, copy the HDK artifacts,
> > > > then move into 'working_classlib' and be able to do cleans, rebuilds
> > > > and tests.
> > > >
> > > > -Nathan
> > > >
> > >
> > >
> > >
> > > --
> > > With best regards,
> > > Alexei
> > >
> >

View raw message