Geir Magnusson Jr wrote: > oh. > > Well, I'll try that - it's a step forward. I do think we need to > rapidly come to a conclusion on what to do. I think we want to have the > drlvm build : > > 1) point anywhere to a hdk/classlib that's prebuilt and just use the > artifacts in it
yep (probably with a reasonable default for those that just want to build 'head'). > 2) be invokable from 'above' (as described below) agreed > 3) change how the dependencies work. I think it's nice to be able to do > what it does, but we also need to have the ability to keep those around > locally indep of drlvm, and just use properties to tell drlvm where to > find those resources too, so that way if I have a regular distribution > of say APR on my machine, I can just use it. > > Now, this is something for all of us to decide, but I imagined our > project this way : > > /drlvm/ > /classlib/ > /tools/ > > /deploy/ Wouldn't it make sense for the dependencies to be up there too, so that they can be shared project-wide? Of course, the full set of dependencies may not be populated if you choose to only build a subset. > with each 'subcomponent' (i.e. classlib, drlvm, jchevm) determining it's > own build and just having a clear way to be invoked form above. Absolutely. It will be very useful to have the builds structured so you can build the world, or just build all classlib | drlvm | tools | ... or just build all LUNI | BEANS | ... I'll cry if fixing a one-liner in the tools requires invoking a whole system build (even if the dependencies are set-up right). > We can then invoke the classlib build and have it deposit it's artifacts > into the deploy directory, and then point drlvm to that and have it > build from there - and NOT build classlib. I agree -- we can where the artifacts are dumped but I agree with what you wrote. <sidebar> So what I imagined is that the dir we call classlib/deploy today is specified to the classlib build script as a variable, so that the global build can tell classlib to dump the artifacts into a peer of /classlib and /jchevm etc; and a more localized build can ask the classlib build script to dump them elsewhere. But that is a minor detail IMHO. </sidebar> > Further, building on the HDK stuff, I think we'd also want to be able to > do something like : > > /drlvm/ > > /hdk/ > hdk1/ > hdk2/ > > and point drlvm to build against one of the hdks.... Just checking, we agree that these /hdk directories are not stored in SVN, right? again they are args that tell the /classlib, /drlvm, etc. where to get/put build time artifacts? Just a shared space on disk with a structure that is understood by all build participants? Regards, Tim > I really appreciate how easy the existing build makes evaluation of > drlvm, but we should consider if we can reuse to get us towards the > above, or if we have to re-do in a manner more like classlib, jchevm, etc... > > geir > > > Vladimir Gorr wrote: >> Geir, >> >> unfortunately the DRLVM build system doesn't allow to make you wish. >> Obviously it should be modified to build the recent version of class >> library >> from SVN >> using the original build system. Whether do I correctly understand you are >> interested >> to have only one build system for class library? And your preference is not >> the DRLVM one, right? >> >> Thanks, >> Vladimir. >> >> >> On 6/8/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >>> Maybe I wasn't clear. >>> >>> I dont' want DRLVM to then try and build that classlib, I just want it >>> to use it, as is... >>> >>> geir >>> >>> >>> Geir Magnusson Jr wrote: >>>> Ok - perfect - and this assumes the standard location for jars/dlls? >>>> >>>> Denis Sharypov wrote: >>>>> To stop using the auto-download classlib and harmony JIRA fetches, >>>>> and point the build at the existing classlib that's stored locally >>>>> you should do the following: >>>>> >>>>> edit harmony/enhanced/drlvm/trunk/build/make/win.properties or >>>>> harmony/enhanced/drlvm/trunk/build/make/linux.properties file: >>>>> >>>>> comment out >>>>> >>>>> remote.CLASSLIB.archive=-r 385366 >>>>> >>> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk >>> >>>>> remote.CLASSLIB.archive.type=svn >>>>> >>>>> and add >>>>> >>>>> CLASSLIB_HOME=<relative path to classlib> >>>>> >>>> --------------------------------------------------------------------- >>>> 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] > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
