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: [classlib] Preprocessor - an attempt at [even more] clarity
Date Fri, 03 Nov 2006 15:49:23 GMT
Geir Magnusson Jr. wrote:
> One copy (the master) on which the IDE and cmd line tooling does both
> the "file/directory" masking (dealing with the differences that aren't
> just in class files - add and remove classes, etc - the "lookaside
> table") as well as code xform.
> 
> I never thought of having that intermediate form (dev1/2/3) as being
> fundamental to the model, although it's a nice option. I can see how it
> will be nice for editing, but I'm instinctively suspicious of it being
> necessary).
> 
> Why?
> 
> Because I can imagine that as a SE programmer, I would want 1 of 2 things :
> 
> 1) clean code to work on for a specific target (say SE 5)
> 
> 2) a hybrid version of your dev1 that only has the glop for a subset of
> the platforms (say just Java SE 5 and Java SE 6) in it, so I can focus
> across just those two.
> 
> Maybe it's just me, but I'd probably want the distractions of other
> platforms out of the code so I can get better into the 'flow' when
> developing.
> 
> So that's why I think of dev1/2/3 as being the virtual code (not key to
> the process) that can be generated either by the tooling onto disk as a
> temp form, or by IDE virtually in situ.

but how do you resolve the ambiguity of where new/moved code should go
in the master if you are working in a dev that has lost the context of
other streams?

it's the point that was made here:
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200611.mbox/%3c454A4185.6070700@sablevm.org%3e

it would be cool if we could do that.

> Further, there aren't just N dev forms for the N distinct
> platforms/version, but rather the freedom for combinations where they
> make sense (a dev w/ SE 6 and SE 6 only)
> 
> If you want to generate a dev1 and work on that on disk, great - do it,
> you can go back to master.

Only if the reverse mapping is exact, which I believe means that you
need to take the full master context along with you.

> If you want to just work on the single master tree, you can do that if
> the IDE has the tooling.
> 
>>
>> We also talked about how patches to the source that Mrs CLDC developer
>> sees can be matched back to a devtarget.
> 
> Yes, I did read it :)

I was changing focus, you knew that <grr>

> Thanks for the example.  I guess the difference is that I virtualized
> the dev1/2/3 form and used tooling to just let people work on master
> directly, or let dev1/2/3 be concrete as a temporary form for
> convenience, as I noted above.
> 
> Or in simpler terms, the model differences seem to boil down to this.
> Given N possible targets:
> 
> 1) Master is concrete, dev1..M (where M possibly > N) are generated
> simply for ease of use either as concrete tree on disk or virtually in IDE
> 
> 2) Master is virtual, dev1..N are concrete, one dev form is Most Favored
> Nation Status so something coherent can be shoved into SVN (Q: is MFNS
> necessary? Nice, yes, but necessary?)

Yes, that seems to be the difference.  I'd like to be convinced that
working in dev1..M code is possible in approach (1).

Regards,
Tim

-- 

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

Mime
View raw message