RFC: micro-libgcj merge proposal

[Joel Dice]

Thanks for your feedback, Andrew, David and Per.

On Fri, 13 Jan 2006, David Daney wrote:
> Per Bothner wrote:
>> David Daney wrote:
>> 
>>> Q: Who gets to decide what is in micro-libgcj

Whoever is willing to do the work.

>>> ...
>>> I cannot use micro-libgcj if it contains too small a sub-set of libgcj. 
>>> Likewise I don't want it to be too big.  My requirements do not cleanly 
>>> fit into any of Sun's J2ME profiles so I don't want that either.
>> 
>> 
>> That is why we need pre-processing.  At configure time you select a
>> "profile" - either a "standard" named profile or a custom profile.
>> Each profile sets set of pre-processor flags, such as
>> "+java.lang.ClassLoader" (if the profile includes ClassLoader support)
>> or "-java.lang.ClassLoader" (if it doesn't).  Then at 'make' time
>> (though it could be 'configure' time, I guess) we run a pre-processing
>> filter and the normal .java files to give the modified files in a
>> separate directory, before compiling the latter.
>
> Well I like Per's proposal.  I think something like this would be extremely 
> useful.  However it does not seem like that is what is being proposed.

Indeed, that's not what I'm proposing, at least to start with.

I understand and agree that the ULIBGCJ directives should to be replaced 
with finer-grained options, but we need to start somewhere, and that's 
what my proposal is about.

As for preprocessing Java files, I agree that it would be the best 
solution if the maintainers of said files are amenable.  So I ask again, 
who are these maintainers, in the long run?  Are they the libgcj folks or 
the GNU Classpath folks?  Or are they the same people in either case?

  - Joel