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 - CHECKPOINT
Date Thu, 02 Nov 2006 22:57:44 GMT

Tim Ellison wrote:
> Geir Magnusson Jr. wrote:
>> Etienne Gagnon wrote:
>>> Geir Magnusson Jr. wrote:
>>>>> The "communication" aspect of 2 can be quite helpful when doing
>>>>> system-wide changes.  Just think about the effect of simply doing a
>>>>> system-wide reindentation of source code; this is a nightmare when
>>>>> developing using branches, as diff/merge tools are line-based, not
>>>>> syntax-based.  So, if your new indenter moves things across lines,
>>>>> you're in hell.
>>>> So here's where I'm starting to believe I'm missing something
>>>> important :
>>>> Can you give me an example of the "communication" that you imagine
>>>> taking place here?  That's the part I'm just not grokking here.
>>> How about: j2se5 developers, seeing that his planned modification to
>>> some code will lead to utterly broken nearby j2se6 (commented) code
>>> fragments, steps on this mailing list and asks j2se6 developers to help
>>> him find the most harmless way to do the change (or, at least,warn them
>>> about the problem)?
>> Ok - we do that now.  I thought you were saying that your tool added
>> somehow to communications.
>>>>> I am not saying that using the tool should replace using branches for
>>>>> all situations, but there are situations where it would be more
>>>>> effective not to use branches when the code is mostly identical.  
>>>> I want to avoid branches at all costs.
>>> [somewhat off-topic]  I think that we should consider tools/approaches
>>> on their merit.  Sometimes, branches are the right solution...  You
>>> wouldn't want to use syntax-processing instead of branches for managing
>>> sandboxes. ;-)
>> I'm trying to figure out the merit here.
> I believe that there will still be a role for branches, both for
> sandboxes to experiment as Etienne said, and for the maintenance streams
> of our releases.

Of course we aren't going to ban branches.  The context is branching for 
mainline code.  Lets stay focused...

>>>> Clearly there's some confusion here.  My goal is to
>>>> 1) Avoid branches at all costs so we can share as much code, and get as
>>>> much benefit for collaboration between different versions, and different
>>>> platforms, if that happens.
>>> Agreed.
>>>> 2) make it simple to work in either the 'master' code, or the 'target'
>>>> code through tooling, including standard IDE activities like debugging
>>> Agreed.
>>>> 3) make it easy for users to report bugs based on 'target' code,
>>>> including patches and line numbers
>>> Ah!  That's something to add to my requirements.  Fine!  I hadn't
>>> included the "patches" thing into account.  It doesn't break what I've
>>> exposed so far; it simply adds to it.
>> It has to be the case - we'll do snapshots and distributions of
>> "src.jar" and when a developer goes into the debugger, they need to see
>> normal Java SE 5 code.
> Agreed -- our src.jar will be 'normal' Java code without multi-target
> mark-ups.
> <snip>
>>> That's neat.  I like it.  Yet, we would encourage developers to work and
>>> submit patches using devtarget code, instead of releasetarget code.
>> I don't know this terminology.  I was using "master" being the code in
>> SVN, and "target", being the code Y, so the map is :
>>   master == devtarget
>>   target == releasetarget
>> right?  Ok.
> 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?

>> I want to work in the master code w/ an IDE plugin that lets me think
>> I'm in target (and lets me flip back to master).  No preprocessing of
>> the tree is required to develop.
>> However, end-users - people who take our JDK and work with it, will
>> report bugs with stacktraces and line numbers that are from
>> target/releasetarget code.
> 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.

>> So what to do with a patch?
>> I can either
>>   patch -p0 << reverse(patch.file)
> I don't understand how you will ensure there is enough information in
> patch.file to make the reverse() function exact?  I proposed that our
> releasetarget code contains tie-points where it is out of sync with the
> closest devtarget by some number of lines.

I don't understand why you'd bother.  If you know that patch P creates 
Y' from a given Y, and you can always create Y as you know everything to 
do the xform from master source and the platform name, everything is known.

>> on the main code or use patching facilities in an IDE to patch the
>> transform view
>> Man, this tooling is going to be fancy! :/
>>> In other words, here's how I see the distribution(s):
>>>  - Binary j2se5 Harmony release:  includes j2se5release src.jar for
>>>    end-developers using debuggers to step through API code.
>>>  - Source j2se5 Harmony release: API are in j2se5dev form.  The build
>>>    process uses the processing tool to generate j2se5release src.jar.
>>>  - Binary j2se6 Harmony release:  includes j2se6release src.jar for
>>>    end-developers using debuggers to step through API code.
>>>  - Source j2se5 Harmony release: API are in j2se6dev form.  The build
>>>    process uses the processing tool to generate j2se6release src.jar.
>> Yes.
>>> Why?  Because reverse works much better with devtarget than
>>> releasetarget code, and the communications benefit of devtarget that are
>>> lost in releasetarget code (because of stream code erasure).  In
>>> addition, using smart IDEs, there wouldn't be much difference for
>>> developers between the "visible" formats of dev vs release code when
>>> working on it.
>> I don't think it matters, as I think that most people interested in
>> working on the code will just check out of SVN.
>>>> for X being a single class.  To produce a complete target source base,
>>>> walk the single source tree as defined by a 'platform descriptor' :
>>> I don't really understand the "platform descriptor" thing, yet I think
>>> that it is, somehow, an orthogonal issue to the discussion above.
>>> [Remember my long message describing 2 levels of processing:
>>> file/directory-level and source-level.]  My first prototype tool would
>>> attack source-level processing (discussed above), to validate the
>>> approach.
>> Right - the "platform descriptor" is the data that the
>> file/directory-level thing uses.
>>> Maybe you could try rephrasing your file/directory-level (right?)
>>> proposal?  How does it differ from Tim's proposal?
>> I get lost in who's proposal is who's.  I thought we were working
>> towards one collectively owned solution.  can you describe what you
>> think Tim's, your's and mine are?
> It's all one proposal.  Etienne's principal idea with a few others
> meddling on the side :-)
> Regards,
> Tim

View raw message