Simple, as always, was the plan.
I hadn't even thought of #include, but that sounds great.
Spec, then, is simple. We write a program
Here's the spec as I see it:
1. All files come in the format <filename>.pre (in the case of Object.java,
it would be Object.java.pre).
2. A rule is added to the makefile that processes X.pre into X using "jpre
X.pre -o X $JPRE_DEFINES", where JPRE_DEFINES contains things
like -DNO_SANITY_CHECK and -DLOW_MEM (optimize code for low memory).
3. The program, jpre (Java Preprocessor), will recognize these directives,
which I don't feel I need to explain here unless someone here doesn't know
C:
#ifdef X
#ifndef X
#if eq X Y
#if neq X Y
#if gt X Y
#if lt X Y
#if ge X Y
#if le X Y
#else
#endif
#include <filename> (gets the file relative to classpath root)
#include "filename" (tries file in current dir, then goes to classpath
root)
4. We should come up with a standard list of macros and not go beyond it
without asking everyone else. Classpath should be easy to configure. (I
have in the back of my mind a nice little config script, like Linux's,
except a lot simpler since there's a lot fewer options.) We could even have
jpre check to make sure no unauthorized macros are being used, with some
kind of macros.allow file. Possible options I can currently think of right
now:
JDK1_1
JDK1_2
LOW_MEM (optimize code to use as little memory as possible, rather than
speed, as we currently look at)
NO_SANITY_CHECKS (do not perform sanity checking)
LESS_NATIVE (try to use absolutely as little native code as possible).
MORE_NATIVE (move more stuff into native than usual).
DEBUG (set the level to the level you want, 1-4, which we can define
later.)
5. I have not thought this through yet, but these defines could be
configured on a package-level basis
using -Djava.beans:LOW_MEM, -Djava.lang:LOW_MEM etc., etc. jpre could deal
with these and set whatever it needs to based on the package being compiled.
I'm not sure this is a good idea, though, so I'd leave it out at first.
6. No -I directive. -D is enough. No macros, either. Ever.
One possible enhancement, not necessary, would be to add the directives
#elseifdef, #elseifndef, and #elseif.
The goal of the preprocessor is explicitly to give very limited
precompilation support. Complex expressions need not and should not be
supported, and macros would confuse more than help.
I can bang the thing out over the weekend if everyone likes it.
--John Keiser
> -----Original Message-----
> From: Paul Fisher [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Fisher
> Sent: Thursday, August 06, 1998 8:13 AM
> To: Classpath
> Subject: Re: 1.1 vs. 1.2 revisited
>
>
> "John Keiser" <[EMAIL PROTECTED]> writes:
>
> > Paul, I know you were opposed to this sort of thing earlier, but in
> > the case of 1.1 vs. 1.2 compilation, as well as this sanity check
> > thing, there is a lot of good that would be done.
>
> I still don't believe that we need to ship a 1.1-to-the-exact-spec
> version. I don't see anyone getting upset with a hybrid 1.1/1.2
> version, which is fully compatible with 1.1.
>
> In the case of sanity checks, and possibly "other" cases which I've
> run into (I'd like String.intern() to be compiled as either native or
> non-native), I do feel that some type of simple/extremely-primitive
> pre-processor might come in handy. Writing something in perl should
> be enough. (or we could always use ANTLR (www.antlr.org) for a Java
> pre-processor.) Maybe, John, you'd like to write up a spec and get
> everyone's opinion? _Simple_ #ifdef and #include primitives should be
> plenty.
>
> --
> Paul Fisher * [EMAIL PROTECTED]
>
>
