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: Supporting working on a single module?
Date Thu, 25 May 2006 14:48:46 GMT


Oliver Deakin wrote:
> Geir Magnusson Jr wrote:
>>
>>
>> Oliver Deakin wrote:
>>> Geir Magnusson Jr wrote:
>>>> On thing to think about (which I didn't realize until now) is that 
>>>> HDK should sit above /classlib in the tree right?  the VMs will need 
>>>> it as well.  I imagine :
>>>>
>>>> enhanced/
>>>>     classlib/
>>>>     drlvm/
>>>>     jchevm/
>>>>     bootvm/
>>>>
>>>> So maybe add a
>>>>
>>>>    enhanced/common
>>>>
>>>> directory in which the HDK sits by default?
>>>>
>>>> I'd like to avoid the structural balkanization of making classlib an 
>>>> island.
>>>
>>> I had imagined that HDKs would be packaged up as zips and made available
>>> in a similar way to snapshots, rather than having a tree of binaries 
>>> checked into
>>> SVN. 
>>
>> I think we all did.  I don't know what about the above leads you to 
>> assume I would have wanted this in SVN.
> 
> I think I'm just easily confused ;)
> So are you suggesting that the HDK should sit in a concrete location
> relative to whichever component (VM/classlib) we are working on, or
> that the HDK zips should be stored in SVN? (or something else...?)

I think that the HDK should be a zip/tar that you download from our 
distro locations(s), and dropped into

a) a well-known default location

b) anywhere you want so you can set a pointer if you have more than one

and no, they aren't stored in SVN.


> 
>>
>>
>>> IMHO keeping it as a zip makes unpacking it where you want very simple,
>>> allows you to easily keep a "known good" HDK configuration locally 
>>> (in the
>>> form of the original zip) and makes it very easy to get previous 
>>> versions of
>>> the HDK (just download an earlier zip).
>>> I'd be interested to hear what general consensus on this matter is, and
>>> how mailing list members would prefer the HDK to be provided.
>>
>> Keeping zips around and all that is great, but is it that Eclipse 
>> would break having it up and above the root of the project tree?
> 
> I dont see this as a problem.
> If you use the Ant scripts to build (which can be used within Eclipse), 
> then
> an hy.hdk property (described in one of my other mails in this thread) that
> can be set to point at an HDK will enable you to use any location.
> If you wanted to work on Java code as a Java project under Eclipse,
> then you should only have to point Eclipse at the jre under your HDK
> and Eclipse will build against it.

Cool

> 
> Regards,
> Oliver
> 
>>
>> geir
>>
>>>
>>> We discussed [1] that having separate HDKs for each VM and for classlib
>>> makes sense - as long as we keep them in a uniform shape, then they 
>>> can easily
>>> overlaid onto each other to allow a developer to work on the classlib 
>>> and the
>>> VM of their choice.
>>> I don't see this separation of classlib and VMs as a bad thing. I 
>>> think that
>>> having a VMI enabling us to develop the classlib and VMs as distinct 
>>> units,
>>> and developing using potentially disparate methods and build systems 
>>> that
>>> most suit that component, is one of the cool things about Harmony!
>>
>>
>>>
>>> Regards,
>>> Oliver
>>>
>>> [1] 
>>> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/%3c446D8460.9050105@googlemail.com%3e

>>>
>>>
>>>>
>>>> geir
>>>>
>>>> Oliver Deakin wrote:
>>>>> Hi all,
>>>>>
>>>>> I have opened HARMONY-485, which proposes an additional doc for the 
>>>>> website describing the HDK and its contents.
>>>>> The layout of the HDK described in the doc matches that produced by 
>>>>> the build script alterations raised in
>>>>> HARMONY-469.
>>>>>
>>>>> I hope that eventually (once the natives are modularised
>>>>> and build scripts are altered to understand/use the HDK) the doc 
>>>>> will expand into a more full description of how developers can use 
>>>>> the HDK to rebuild Java/native code.
>>>>>
>>>>> Regards,
>>>>> Oliver
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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