On Fri, Jan 23, 2004 at 12:15:27AM -0600, Adam Majer wrote:
> On Tue, Jan 20, 2004 at 02:00:12PM -0500, Andrew Pimlott wrote:
> > Irrespective of the testing issue, it seems obvious that just as the
> > jikes source package is the wrong place for these wrappers (why
> > should the compiler know about different runtimes?), so are the JVM
> > source packages (why should the runtime know about a compiler?). It
> > would make much more sense for the JVM packages to register their
> > standard libraries as alternatives (the alternative could either be
> > the library, or perhaps more generally, a file containing a list of
> > library files). Then jikes as well as any other compiler that is
> > not bundled with its own standard libraries could find them in the
> > same way. After all, it is silly to implement a solution that works
> > only for jikes.
>
> So, if someone wants to use jikes with kaffe, they will have to type
>
> jikes -bootclasspath 'some kaffe paths' hello_world.java
If they absolutely must use kaffe's libs, yes. If they just type
jikes hello_world.java
they will get the libs with the highest priority alternative. (The
symlink might be /usr/share/java/bootlibs, and it could contain a
list of jars, so the jikes wrapper script would do "jikes.real
-bootclasspath @/usr/share/java/bootlibs)
> The point of the java-wrappers is for people to install one of these
> and then simply type:
>
> javac hello_world.java
I think my suggestion meets this goal.
> Or to have a java package in main compiled with javac and just having
>
> Build-Depends: jikes-kaffe
If a java package needs jikes and kaffe, it can depend on jikes and
kaffe, and run "jikes -bootclasspath 'some kaffe paths'". This
seems much cleaner than adding an artificial package for the
combination of jikes and kaffe.
Andrew
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
