micro-libgcj merge reconsidered

Tue Jan 17 10:11:00 GMT 2006

Joel Dice wrote:
> On 2006年1月16日, 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/