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 'working_classlib/deploy'. * 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. -Nathan On Feb 17, 2008 4:24 AM, Alexey Petrenko <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: > > > 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 <[EMAIL PROTECTED]> 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 > > >
