This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: fix for CLASSPATH/classpath switch behaviour


Tom Tromey <tromey@redhat.com> writes:
>  
> I'd like to see this patch refined in three ways:
>  
> * It leaves jcf-path.c alone, meaning that the function names and
>   comments therein will be confusing, and

Actually, looking at this patch I realise this problem is bigger than
I thought.

The comment in jcf-path.c says:

  We support several different ways to set the class path.

  built-in system directory (only libgcj.jar)
  CLASSPATH environment variable
  -classpath overrides CLASSPATH
  -CLASSPATH option - overrides CLASSPATH, -CLASSPATH, and built-in
  -I prepends path to list

I think this is completly different to Sun's tool.

With Sun's tool:

  -classpath supplements the system and CLASSPATH env var

  -bootclasspath allows the system classes to be overriden, or more
   accurately it allows a new core java lib to be selected

My change causes our GCJ switch -classpath to do override the
CLASSPATH env var. If we want to behave like Sun we shouldn't do
that... perhaps -classpath should do what -I does.

So, in summary, I think we need the following GCJ switches:

  -classpath  appends extra class locations to the system and
   CLASSPATH class paths.

  -bootclasspath and -CLASSPATH overrides the CLASSPATH and builtin


Anyone any views?


For now I might just finish off the patch I submitted last night,
it's a big help to have -classpath do (even nearlly) the right thing.



Nic


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]