2008/2/18, Nathan Beyer <[EMAIL PROTECTED]>: > 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 access. > * 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 HDK. > 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. -- Alexey > > -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 > > > > > >
