Announcement: micro-libgcj

[Andrew Haley]

Joel Dice writes:
 > On Fri, 6 Jan 2006, Andrew Haley wrote:
 > 
 > > Joel Dice writes:
 > > > For those who are interested, I've released a lightweight version of
 > > > libgcj which is useful for creating small standalone executables using
 > > > GCJ.  For more information, please see the Sourceforge project site:
 > > >
 > > >    http://ulibgcj.sourceforge.net
 > > >
 > > > Feedback is welcome.
 > >
 > > This is very welcome!  Back in the early days of gcj we had
 > > lightweight library, but we lost it as we gradually drifted towards
 > > full compatibility.
 > >
 > > It would be nice if we could figure a way to merge the code bases.
 > 
 > I'd be happy to perform this merge if there's a good chance it will be 
 > accepted.
 > 
 > I'm guessing that the proper way to do this is to start with the code 
 > in libjava/ and add a lot of these:
 > 
 > #ifndef LIGHTWEIGHT_LIBGCJ
 >    ... // stuff that isn't wanted in the lightweight build
 > #endif
 > 
 > and a few of these:
 > 
 > #ifdef LIGHTWEIGHT_LIBGCJ
 >   ... // stuff that is dumbed-down for the lightweight build
 > #else
 >   ... // more complicated version for the heavyweight build
 > #endif
 > 
 > and just not build or link files that aren't needed by the lightweight 
 > version.
 > 
 > Would the clutter caused by these extra directives be acceptable?

That would suit me well, but there may be some quasi-religious
objections to preprocessing.  As in "How can you do this?  Java
doesn't have a preprocessor!"  :-)

In all seriousness, we only have two routes: either preprocess or keep
micro-libgcj on a separate branch and repeatedly merge.  I don't like
either objection, but it seems to me the second is worse.

 > A more difficult question is how would the Java sources be handled, 
 > considering they are not pre-processed?  My choice would be to 
 > preprocess them, allowing the directives above, instead of maintaining 
 > a separate tree.  This would of course be complicated by the GNU Classpath 
 > merge.

It would, yes.

 > Finally, would it be worth delaying such a merge until gcjx is ready?

I can see no benefit in waiting.

Andrew.