Re: classpath question

[Jeff Sturm <jeff dot sturm at appnet dot com>]

Anthony Green wrote:
> Tom and I were thinking of changing this to /usr/share/gcj/libgcj.zip.  The
> idea being that the compiler would put every /usr/share/gcj and every .zip
> and .jar file found in there in its classpath.  For instance, you could drop
> gnome-gcj.zip in there and it would just show up in your classpath
> automatically.

That would only happen when -fclasspath is not used?  That's probably
OK, though I'm not sure how useful it will really be.  I personally
dislike cluttering up system directories with extra packages.  For that
matter, I tend to use -fclasspath=... in my makefiles in preference to
setting CLASSPATH, which probably defeats the feature you propose.

Class archives in ${prefix}/share/gcj should probably be restricted to
gcj-specific classes, as the name implies.  There probably should be
other naming guidelines for  general-purpose class archives that may be
shared by kaffe, gcj or the JDK.

A related issue is the runtime classpath.  Should programs compiled by
gcj also search /usr/share/gcj at runtime, or should they use the same
classpath as the compiler?  Right now libgcj.zip doesn't appear in the
java.class.path system property; we may have to fix that someday for
class resources.  I've been considering a _Jv_Classpath global variable
initialized in jvgenmain, similar to what we have for properties.

I'm OK with it, if you think it will be useful.  While you're making the
change, you might consider renaming to libgcj.jar since .zip really
ought to be deprecated.

Jeff