micro-libgcj merge reconsidered

Mon Jan 16 21:56:00 GMT 2006

Joel Dice wrote:
> Hi all.
>> Thanks to everyone who contributed to the discussion following my 
> proposal last Friday.
>> Reading through that discussion, I found that there are two major 
> concerns. The first is that micro-libgcj does not adhere to any 
> existing standard, nor does it provide any well-defined criteria to 
> determine what features it should or shouldn't have. It has a guiding 
> principle ("smaller is better"), but everyone has his or her own idea of 
> how that is best achieved.
>> The second concern is that the cost of maintaining the Java source files 
> will be high whether we maintain them seperately from the J2SE-targeted 
> classpath or maintain a unified tree with preprocessing.
>> In light of both of these concerns, I think the advice of Steph 
> Meslin-Weber and others is most appropriate - create a branch for 
> micro-libgcj as proposed, but without intending to merge it into the 
> trunk. Others may then use that branch as a basis for their own 
> branches and take them in whatever directions they care to. Elements 
> from any of these branches may then be merged back into the trunk if and 
> when there is demand for them.
>> How does that sound?

That would not be my preference.
While creating a branch is likely the right thing to do, starting with 
the assumption that it would not be merged back is not at all appealing 
to me.
I thought we were close to a consensus that Per Brothner's preprocessor 
idea was close, if not identical, to the preferred approach. It seems 
to me that most people would not object to this and we would have a very 
good chance to merge it back to the mainline.
I think preprocessing is the only way to make a u-libgcj useful to 
enough different people to make the entire project worthwhile. In case 
you could not tell, I am strongly in favor of the preprocessor approach.
I think the first step is to get libgcj building with a preprocessor. 
That will mean some autoconf/automake hacking. After that it should be 
fairly easy to mark up the code with the preprocessing directives.
I cannot do anything WRT this for the rest of this week, but I really 
was planning on looking at it next week. I am planning to start with 
the autoconf/automake things, unless someone else has it working by then.
David Daney