micro-libgcj merge reconsidered

[Per Bothner]

Joel Dice wrote:
> On Mon, 16 Jan 2006, David Daney wrote:
> 
>> Joel Dice wrote:
>>
>>> 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.

Creating a new branch for each "configuration" is clearly unsupportable.
And since we know different "nicro-applications" will require differeny
Java sub-sets, we will need some kind of configuration mechanism.

>> 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 agree,

>> 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 did not get that impression.  From what I read, neither of the libgcj 
> maintainers sounded convinced that this was the right approach.

I think the primary concern is libgcj/classpath divergence.  If we
agree wity classpath maintainers to put in the appropraite
pre-processing comments, then that concern goes away.

In any case, a micro-libgcj branch should use pre-procssing to
configure different profiles.  We can later merge those modified
java files into mainline.

> I already consider micro-libgcj worthwhile regardless of what happens 
> next.  I do agree that the preprocessor approach is best for 
> micro-libgcj. Whether it's best for the libgcj trunk or for GNU 
> Classpath is another question, and one which I'm content to let the 
> maintainers of those libraries decide.

I guess we're close to agreement.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/