harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [drlvm] build -unhook the classlib build and point to the existing in-tree one
Date Sun, 11 Jun 2006 21:49:47 GMT


Tim Ellison wrote:
> 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').

Yep.  I assume we'll just document the defaults, and make it easy to
point to "other places"

For example, if I were working on APR and using DRLVM+Classlib to test
it, I'd want to point to the active APR development project in my tree.

> 
>> 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.

Yes, we talked about that before, IIRC, a long time ago.

So a /deps directory, with a top level

   ant -f deps.xml

(or whatever) to go fill it in.

> 
>> 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).

Right - I think the "world" should be parlallel to "classlib" so you can
just do whatever you want in classlib w/o worrying about the world.
This is what I had suggested earlier based on the suggestions of Garret
on using svn switch to do it cleanly.

> 
>> 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>
> 

Exactly, which is why I was jumping up and down so much about The One
HDK to Rule Them... :)

>> 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? 

Right.  Definltely. Of course.

> 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?

Yes.  I'd assume we can put them anywhere, but figure we should agree on
some kind of "best practice" default that works well for the majority of
cases, yet still giving the freedom to put the hdk on Planet Mongo, if
that's where you so choose.

> 
> 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 <geir@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
>>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>
>>>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message