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: [classlib] Preprocessor - an attempt at [even more] clarity
Date Fri, 03 Nov 2006 12:53:08 GMT

Tim Ellison wrote:
> Geir Magnusson Jr. wrote:
>> Tim Ellison wrote:
>>> There are multiple 'devtarget's -- each contains all the source code
>>> marked-up for every target being developed, but each is distinct by
>>> having different targets uncommented.  Since each devtarget contains the
>>> entire source code it is possible to accurately transform from any one
>>> devtarget to any other devtarget.  One of the devtargets is actually
>>> stored in svn, and that is the canonical form of the devtarget code.
>> So that's 'master'. and everythign else is a transformed master, right?
> Yes, but some transforms preserve all mark-up and are used to switch the
> compilable form between different targets (these are the 'devtarget's);
> and some transforms are mark-up-lossy and are used to provide the end
> user compilable form (this is the 'releasetarget').

Yes, I figured that out last night when I was driving to dinner. Let me 
  see if I have it right :

      /   |    \
     /    |     \
    /     |      \
dev1 <-> dev2 <->dev3
  |       |        |
targ1   targ2   targ3

where in your case, master doesn't exist (consider it virtual), dev1/2/3 
are compilable under whatever platform they are targeted to yet contain 
all the stuff for other platforms, and targ1/2/3 are 'clean code' code 
the target platform.

There exists a transform process

    interDev(dev1, 2) -> dev2

which is really conceptually

    masterToDev(devToMaster(dev1), 2)

(if you had a master) and further

    toCleanTarget(dev1) - > targ1

('normal' code for target platform)

>>> Screech -- the releasetarget, by definition, does not contain the source
>>> for all possible targets so that it is consumable by end-users.
>> That is correct.
>> The only code that contains all code is master.
> Not in the technique that I'm talking about.  All devtargets contain all
> the code (but they differ in which code is compilable and which is in
> comments).

Right - because you don't have a master

> Let me try using very simple example for my favourite type, assuming we
> were doing CLDC and SE1.5 development simultaneously. 


Thanks for the very nice example.  That example conforms w/ my picture 
of how things might work (although I suspect things could get *very* 
ugly to work with in the intermediate dev1/2/3 form, but I think that 
some real use cases will tell us that)

> We then talked about how the different devtargets can be stored in
> different working directories for use by Harmony developers with
> file-based tools, or (thinking about it for a second now) it could be an
> on the fly processing to/from canonical form on disk by the IDE editor.

Yes - that latter part is exactly what I've been advocating :

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 


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 

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.

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.

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

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


View raw message