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 Tue, 23 May 2006 17:54:09 GMT
Post J1 catchup.  Just minor comments, am trying to read the thread 
through...

Mark Hindess wrote:
> On 10 May 2006 at 8:07, Geir Magnusson Jr <geir@pobox.com> wrote:
>> AS a matter of fact, I think that the hdk is simple a tar of the junk 
>> created by a "make the world" build...
> 
> I wouldn't have put it quite like that, but yes perhaps that is correct.
> I'm saying that deploy/hdk tree should be created/used by a "make the
> world" build in such a way that compiling a module would be the same as
> if you have just untar'd an hdk snapshot.  This is possible/easy if no
> module directly references another except via the "junk" in the hdk
> (specifically the jre/lib/boot jars for java code).

I'm going to see where this thread winds up, but I'm still convinced 
that the HDK shouldn't ever be modified, that the contents should be 
copied out to a "working HDK" and then things local to where you are 
working (the module) copied in and overlaid.
>>
>> The following is an example of having the full tree ('full_checkout') at 
>> the same time as a hdk ('binary snapshot aka hdk') with three work areas 
>> (just the prefs checked out from SVN, the RMI contribution from Intel 
>> and the RMI contribution from ITC)
>>
>> /your_see_drive :)
>>     /full_checkout/
>>            /deploy/
>>                 artifacts
>>            / whatever/
>>     /binary snapshot aka hdk/
>>            /deploy/
>>                  artifacts
>>     /checkout_of_pref_only/
>>           build.props (points to /binary snapshot aka hdk/)
>>           /modules/
>>               /pref/
>>     /contribution_1_from_SVN/
>>           build.props (points to /full checkout/)
>>            /modules/
>>                 /RMI from Intel/
>>     /contribution_2_from_SVN/
>>           build.props (points to /full checkout/)
>>            /modules/
>>                  /RMI_from_ITC/
>>
>>
>> That way, you can dork w/ the full_checkout, fix something, and then 
>> your other work environments that are pointing at it get that fix w/o 
>> any work.
>>
>> I hope my crude art makes sense.
> 
> Yes.  But I'm not sure why I'd need the full_checkout around if I had
> the hdk snapshot though.  And I'm not sure I'd mind having several hdk's
> around; They'd be a more manageable than the code I currently copy
> around.

The point is to have options.  There should be no requirement to have 
the full checkout, but it should be able to co-exist peacefully with 
parallel HDKs of various vintages...

geir



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