> -----Original Message-----
> From: Paul Fisher [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Fisher
> Sent: Thursday, August 06, 1998 3:07 PM
> To: Classpath
> Subject: Re: 1.1 vs. 1.2 revisited
>
>
> "John Keiser" <[EMAIL PROTECTED]> writes:
>
> > Actually, I was trying to accomodate your problem. I don't really
> > like these defines either. But what defines would you use to
> > accomplish your purpose? Will they be general enough to make some
> > general statement?
>
> For instance, Kaffe might require a native intern'd String but Japhar
> would not. So there would be defines based on the VM.
>
Aha! OK, so the defines would be:
VM = (kaffe,japhar,jdk)
VM_VER = ...
Sound right?
(Off-topic, but ... why would Kaffe require a specific implementation of
intern()? Does their VM handle that somehow?)
> > I think jpre should be a separate program ... "compiles only under
> > guavac" is not the intent of the project, far as I know.
>
> guavac is the only free Java compiler out there. So it's the only
> logical one to use for compiling GNU Classpath.
>
Makes sense to me. As long as we make it so that any extensions we use can
be harmonized with the base javac (as jpre can), there's no problem. Only
problem would come in if we used stuff like Kiev's extensions. Though that
could even be put into a preprocessor define:
COMPILER = (javac,guavac,kiev).
COMPILER_VER = ...
Remember, most of the time we won't even think about these directives. They
are only for special cases. Everything should be able to support javac.
There could be parts that will not support certain VMs; for example, I can't
make java.lang.Class and java.lang.reflect.* work with VM.
> > Is guavac written in Java at all?
>
> It's all C++.
> http://http.cs.berkeley.edu/~engberg/guavac/
>
Cool. No problems there then.
--John Keiser
