Actually, rule 1 should read, "all files that use jpre directives must come
with filename <filename>.pre". All other files should be fine the way they
are.
--John Keiser
> -----Original Message-----
> From: John Keiser [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 06, 1998 12:08 PM
> To: Classpath
> Subject: RE: 1.1 vs. 1.2 revisited
>
>
> 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]
> >
> >
>
>
