harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@gmail.com>
Subject Re: [build] ant utility target to copy working_vm to working_classlib
Date Mon, 18 Feb 2008 01:58:38 GMT
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.
* 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?
* Same result when I copied
'working_vm\build\windows_x86_msvc_release' to
* 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? Same for a working VM.

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.


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