harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [drlvm] build -unhook the classlib build and point to the existing in-tree one
Date Sun, 11 Jun 2006 20:18:31 GMT
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 <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
> 
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

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