Re: Importing GNU Classpath 0.91 on gcc classpath svn branch

[David Daney <ddaney at avtrex dot com>]

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