Importing GNU Classpath 0.91 on gcc classpath svn branch

Thu May 18 17:22:00 GMT 2006

Tom Tromey wrote:
>>>>>>"Mark" == Mark Wielaard <mark@klomp.org> writes:
>>> Mark> I made some notes on how I do these merges so others can
> Mark> improve the process
>> Please update libjava/HACKING with this info.
>> Mark> - Other files should have a "GCJ LOCAL" comment, or are mentioned
> Mark> in the classpath/ChangeLog.gcj file.
> Mark> (Don't forget to svn resolved files.)
>> I think we ought to have a policy of no divergences underneath the
> classpath/ directory. I think we fail this right now, but we can fix
> that.
>> Mark> scripts/makemake.tcl > sources.am
>> I found out yesterday that there are some .properties files that we
> aren't compiling in to libgcj. I'll update makemake to account for
> this.
>> There is a bigger problem here, though, which is that compiling in
> properties files messes up static links. I don't really know what to
> do about this.
>
In general it is a problem, but currently for my specific case, no 
properties files are needed. But when the locale merge happens, this 
may change...
> I know Bryce's locale merge was going to work around this by putting
> the resource bundles into a separate .jar that is read at runtime.
> This seems ok but it does mean that the required runtime support grows
> somewhat.
>> Perhaps someone who uses static linking can think of a good solution.
>
We already have to figure out which classes need to be linked due to 
reflective class access. Properties are really no different.
My suggestion: For now change no code. Do some hand waving on the 
static linking wiki page, and let all those static linkers figure it out 
for themselves. They are a hardy bunch, they should survive.
In my build system I might put all of the known needed properties in a 
file with each line taking the form: --resource foo
We might want to somehow make --resource search for the resources in 
libgcj-x.y.z.jar so that specifying the path to the resource was 
simpler. Perhaps a --libgcj-resource directive that does the same thing 
as --resource, but looks for the resource *only* in the proper 
libgcj.jar file
Then that file would be added to the final link line with the @file 
directive.
I don't much like the idea of an external jar file containing the 
resources. It is too easy to mix up different versions of things.
David Daney