This is the mail archive of the java@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: gcj -bootclasspath doesn't work anymore?


Tom Tromey wrote:
Actually, I was thinking of [a javac-like script] that would also ignore
> javac arguments we don't support: -X, -source, -sourcepath, -target,
> etc.

My inclination would be to add support for those into gcj itself.

One question is: what should we call a javac wrapper?  Should we
call it javac?  I don't think we want to do that, at least by default.
Certainly gcc make install should not install $bindir/javac.  If an
OS has an "alternatives" mechanism, then I think 'gcj -C' or a
wrapper script should be a valid alternative for javac, but we
should not preclude both being installed.

In my Makefiles for Kawa, I used $(JAVAC).  JAVAC defaults to "javac",
except if you configure --with-gcj, in which case it defaults to
"gcj -C".  I think this works well, and minimizes confusion.

So what is the advantage of a shell script that is argument-compatible
with javac, that invokes gcj -C, yet is installed under a different name
than javac?  I don't see it.  It adds an extra layer of indirection and
slowdown, plus its an extra script that needs to be maintained,
compared to just adding the desired functionality into jv-scan.c.

G++ used to be a shell-script, but we moved away from that.

The script Michael Koch sent does this.
I guess I missed that.
--
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/


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