This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: micro-libgcj merge reconsidered
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/