Andrey Chernyshev wrote: > On 7/4/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> >> >> Andrey Chernyshev wrote: >> >> 4) Change the drlvm build so that its deploy tree layout has no >> classlib >> >> files in it. So we can do ... >> > >> > As a first step, I suggest that we make drlvm build completely free >> > from the classlib-related tasks and files, this may help to avoid >> > further confusion. >> >> I don't quite see what you mean. We need to use things from classlib to >> build, like headers. > > I have created HARMONY-753 to illustrate what I mean :) > Some of the things, like icu libraries, are copied twice at the moment - > one time along with classlib binaries "bulk copy" (target > "deploy.copy_classlib") and once more with the > make/components/extra/icu4c.xml for example. > I'm just suggesting to remove those tasks which are obsoleted by the > fact that > we are now using the complete classlib binaries.
Great. Got it. > >> >> > For example, it doesn't have to copy things like >> > icu, seralizer, xalan e.t.c. - they are already taken from pre-built >> > class libraries. >> >> When you say "taken from pre-built class libraries" do you mean >> "pre-build libraries"? >> >> Yes, we don't have to copy those - we really should organize a top level >> dependency tree. I think I posted a note summarizing where we were last >> week. >> >> > If there are no objections, I'm going to submit a >> > patch which will remove some of that stuff from vm build. >> > >> > As a last step, one would remove the copying of the classlib binaries >> > (e.g. deploy.copy_classlib) after we have a top-level build in place. >> >> I think I know what you mean, but I think that we still want this >> option, so that someone could remain working in the drlvm directory. >> IOW, there's no harm leaving it, and the top level build will just tell >> drlvm to build itself into a canonical tree for copying by the top >> level, and finding classlib is up to the top level builder. >> >> Note to self - we'll need to pass the location of the classlib to the >> drlvm as a parameter with a top-level builder... > > I believe CLASSLIB_HOME env. variable can be used for that, right? > One note - it currently used to point to the CLASSLIB root in a source > tree, but may be it makes sense to have it pointing directly to the > classib binaries. We do need header files. > > BTW: drlvm build has a built-in machinery to get the resources from > Internet. Do you think it may make sense to teach it to get the > classlib binaries snapshots from the web site? NO! > I think > remote.CLASSLIB.archive variable in win/lnx.properties can be used > for that purpose, we only need to specify there the binaries location > instead of source tree url. No. You should be able to go get it yourself, unpack somewhere, and point the variable. > > One of the issues here is that VM may not always work with the latest > class libraries, hence hardcoding of the specific classlib snapshot > URL/version in *.properties may be helpful (in the past SVN revision > was used for that purpose). Right geir > > Thanks, > Andrey. > > >> >> geir >> >> >> > >> > Thanks, >> > Andrey. >> > >> > >> > On 6/23/06, Mark Hindess <[EMAIL PROTECTED]> wrote: >> >> >> >> On 23 June 2006 at 17:10, Tim Ellison <[EMAIL PROTECTED]> wrote: >> >> > Rana Dasgupta wrote: >> >> > > On 6/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> >> > >> >>Pavel Pervov wrote: >> >> > >> >> Geir, >> >> > >> >> >> >> > >> >> What's the first thing we do? >> >> > >> >> I'd suggest switching the build to 1.5. >> >> > >> >> >> >> > >> >> The rest will come shortly :) >> >> > >> >> >> > >> >Now that's a plan! :) >> >> > > >> >> > > >> >> > > Hi Geir, >> >> > > Actually what Pavel says makes sense. Not sure what plan we need. >> >> We could >> >> > > do it either way. We can make some changes to the class structure, >> >> loader, >> >> > > and the jit/interpreter, and submit a couple of patches. It is not >> >> the >> >> > > "huge" patch that you have mentioned .. 7-8 files or so. Or we can >> >> switch >> >> > > the build first. This will break drlvm for a short time, and we >> can >> >> > > submit a >> >> > > couple of bug fixes to get it going again. This way, we will just >> >> add the >> >> > > minimum needed for removing the compiler hack. Whatever way you >> >> think makes >> >> > > sense. >> >> > > However, you started this thread with saying "no patch over the >> >> wall" >> >> > > and making this "learning exercise about DRLVM". Where are you >> >> going with >> >> > > this? Do you want to actually enumerate/discuss which source files >> >> need to >> >> > > change and in what way, on this thread so that more people can >> >> participate? >> >> > > >> >> > > Marginally confused :-) >> >> > > Rana >> >> > >> >> > Just for the record, my goal was to avoid 'moving the goalposts' for >> >> > drlvm to integrate with the classlib and run the tests, apps, etc. >> >> > >> >> > If consensus here is that moving to 5.0 (and thereby delaying that >> >> goal) >> >> > is more desirable then I'm happy to go along with it, though I'm >> >> keen to >> >> > get the entire end-to-end story working soonest. >> >> > >> >> > Regards, >> >> > Tim >> >> >> >> My feeling at the moment is that although drlvm and classlib are >> working >> >> together[0], it is evident[1] that things are not really integrated. >> >> I would prefer to see "real integration" before we break[0] things by >> >> moving to 5.0. >> >> >> >> As Geir pointed out recently, we are not just a Class library project, >> >> so perhaps a change of focus is warranted? Perhaps if we can agree a >> >> set of prerequisite goals (involving our JVMs) for moving to 5.0, >> we can >> >> ... err ... encourage this change of focus? >> >> >> >> My prerequisite goals would include things like: >> >> >> >> 1) Fix the (reasonable) 'hacks' that help us get this far with drlvm >> >> integration - e.g. the static libhyprt.a for instance.[2] >> >> >> >> 2) Implement enough of the classlibadapter kernel classes such that >> >> JCHEVM will run 'ant rebuild' in classlib[3]. We have some difficult >> >> problems (thread attach) but there is also a lot of low hanging >> fruit in >> >> terms of missing or incomplete methods. >> >> >> >> 3) Get drlvm loading with the Harmony launcher from Classlib so we >> >> can have both drlvm and IBM VME around for testing. I think this is >> >> important because it will make it easier for people to test with >> either >> >> JVM. >> >> >> >> 4) Change the drlvm build so that its deploy tree layout has no >> classlib >> >> files in it. So we can do ... >> >> >> >> 5) Create the top-level build that can combine the trimmed drlvm >> deploy >> >> tree and the classlib deploy tree to produce a working jdk. (In much >> >> the same way that we currently combine the classlib and IBM VME.) >> >> >> >> 6) Pull out shared dependencies to top-level so we only need one copy. >> >> >> >> >> >> At the moment, I think moving to 5.0 would increase the divide between >> >> the JVMs and Classlib. >> >> >> >> In the meantime there is still plenty of work to do for those that, >> for >> >> whatever reasons, don't find these tasks exciting enough - for >> instance, >> >> the missing java.lang.Character/java.lang.Math methods[4]. >> >> >> >> Regards, >> >> Mark. >> >> >> >> [0] Thanks Geir! >> >> >> >> [1] http://issues.apache.org/jira/browse/HARMONY-651 >> >> >> >> [2] This isn't a criticism; I think these hacks can be justified. >> >> >> >> [3] I tried this the other day. It got to the second (non-comment) >> line >> >> of the first ant script before crashing because >> >> ClassLoader.getResources() >> >> isn't implemented yet. >> >> >> >> [4] >> >> >> http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony.html#pkg_java_lang >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> > >> >> --------------------------------------------------------------------- >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
