Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (herse.apache.org: 216.86.168.178 is neither permitted
 nor denied by domain of geir@pobox.com)
Message-ID: <454B51B5.6020206@pobox.com>
Date: Fri, 03 Nov 2006 09:27:01 -0500
From: "Geir Magnusson Jr." <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Preprocessor - an attempt at [even more] clarity
References: <8E389A5F2FEABA4CB1DEC35A25CB39CE694EF8@mssmsx411>
	 <45473BA9.1070709@gmail.com>
	 <bc79dd600610310412w6b7a64dfo3c4758ddb14409c0@mail.gmail.com>
	 <45474144.5060108@pobox.com>
 <4547431C.5080000@pobox.com>	 <3b3f27c60610311705q1cb2aeb1wa78d0c55fb7f026b@mail.gmail.com>
	 <4547F8D5.9040409@pobox.com>
 <454870F8.8080302@gmail.com>	 <454884DC.7070806@pobox.com>
 <4548A644.6060403@sablevm.org>
 <bc79dd600611010659rb7bd511p998f88c7d6deb591@mail.gmail.com>
 <4548BB62.7050503@sablevm.org> <45496DA6.9000708@pobox.com>
 <454A3BE6.7000008@sablevm.org> <454A3D9F.3090904@pobox.com>
 <454A4185.6070700@sablevm.org> <454A4A9A.4090509@pobox.com>
 <454A53EE.9040505@sablevm.org> <454A5A5C.7040305@pobox.com>
 <454A72C4.5020202@gmail.com> <454A77E8.3010305@pobox.com>
 <454B1C48.3060302@gmail.com> <454B3BB4.3030103@pobox.com>
 <454B46DF.1020001@sablevm.org>
In-Reply-To: <454B46DF.1020001@sablevm.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Etienne Gagnon wrote:
> Geir Magnusson Jr. wrote:
>> [...]
>> 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?)
> 
> I definitely think that it is necessary (where J2SE5 is the preferred
> devtarget), at least during the initial transition to using the
> processing tool.

:)

That still makes it "nice" - because you can always transform the SVN 
tree to any platform anyway.

> 
> It's (I think) the least intrusive method for starting to slowly add
> non-J2SE5 code in the development trunk while letting existing J2SE5
> developers continue developing without changing the way they've been
> using up to now.

Yep.  "nice".

> 
> By leaving the preferred devtarget in svn, the hordes of existing J2SE
> developers will have the choice of continuing to use simple "svn co/ci"
> to work on the code and won't have to learn to use new, yet not fully
> tested tools.

Yep.  "nice" :)

> 
> It also lets the smaller number of non-J2SE5 developers test the
> processing tools and help identify bugs (what!? :-P) and usability
> problems without forcing J2SE developers into doing the same.
> 
> Maybe, in the longer term, it would make sense to have some kind of
> canonical "master" form, and store that in svn, but I am a big fan of
> the least disturbance path, when trying to put in place new processes in
> an ongoing development project.  :-)
> 
> Question: What would be the advantage (in the longer term) of putting,
> in the Subversion trunk, source code in non-compilable canonical master
> form, instead of compilable preferred devtarget form?  Why is the
> existence of "master" so important to you?

I need to go check if where I said it wasn't to be compilable, as I 
don't believe I ever mandated that.  I do think it's going to be 
difficult to achieve though.

I think we both agree that we need a complete, fixed reference point to 
put in SVN. (In that sense, you actually have a master too, actually)

However, it's not clear to me that a master can actually be created that 
is complete for all platforms while still buildable directly w/o 
transforms and look-aside hiding/moving as part of the build process.

If you need to transform and move things around while building, then you 
don't have the model you are advocating.  You actually have the concrete 
master model.  You could cheat, and have both the concrete master tree 
and a preferred platform transform checked in at the same time, but 
that's just the concrete master model with a convenient "generated 
artifact" checkin as well.  That's fine, as long as you remember to 
update both and checkin both on modification.  We do that for the 
website, for example.


Even if we are astoundingly lucky, and we can create a simple buildable 
tree that can magically be transformed across platforms, I think that 
not distinguishing a master form as distinct from other forms is a 
mistake, because for the case of wanting a subset of representation for 
clarity in development (which I'm not sure you acknowledge yet is 
important), transforms are irreversible w/o a fixed master :

    masterToDev(master, 2+3, clean) -> dev2+3

meaning, transform master to contain code for platforms 2 and 3 only (ex 
Java SE 5 and 6), cleaning out all other, compilable for 2 but including 
3 material in comment form.

Then that is no longer a peer to your dev1/2/3 set (where all info is in 
all forms, just compilable on different platforms) but different because 
data for all platforms except 2 and 3 were taken out.

Therefore, I do think we need an explicit master copy, with the dev 
forms as intermediate convenience in whatever forms the developers 
choose to put them in (with all other stuff, subset of other stuff, w/o 
any other stuff...)

As fun as this discussion is, it's all theoretical.  I've never worked 
with multi-platform java code.  I've worked with a lot of multi-platform 
C code, and having the ability to ditch the confusing #ifdef cruft for 
the platforms I'm not working on at the moment would be a very 
innovative and pleasant advancement.  Anyway, this is theory.  The real 
test will be how it actually evolves in code...

geir