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 :
(Master)
/ | \
/ | \
/ | \
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.
[SNIP]
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
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.
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?)
geir
