Re: address@hidden: Re: [GNU Crypto] new make plumbing]

[Raif S. Naffah]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On Mon, 29 Sep 2003 01:54 am, Casey Marshall wrote:
> On Sun, Sep 28, 2003 at 02:45:03PM +1000, Raif S. Naffah wrote:
> > On Sun, 28 Sep 2003 02:31 pm, Casey Marshall wrote:
> > > ...
> > > You should set your CLASSPATH environment variable to reflect
> > > your system. The new Makefiles rely on environment variables,
> > > making them much more flexible.
> >
> > sun recommends against using the CLASSPATH env variable
> > (<http://java.sun.com/j2se/1.3/docs/tooldocs/win32/classpath.html>)
> >, and lots of projects avoid relying on it.
>
> That looks like it is a recommendation for Windows. Make is for Unix,
> and environment variables are traditionally the way to configure
> things on Unix.

they recommend the same for solaris as well 
<file:///usr/java/jdk1.3.1_09/docs/tooldocs/solaris/classpath.html>.


> Besides, CLASSPATH only needs to be set in this instance to configure
> and build (and, even then, only if you are using something like jikes
> that needs to know where the core classes are).
>
> And remember that you can specifiy CLASSPATH on the command line of
> configure, just like JAVAC etc.

the problem with CLASSPATH is that it locks you to a specific set of 
.class set.  usually one needs different sets for compiling the main 
distribution, running it, compiling test classes, and running them.

the ideal would've been to define env vars other than CLASSPATH (for 
different cases) and build that into the @JAVAC@ and @JAVA@ commands; 
at least something like @JAVA_CLASSPATH@ and @address@hidden


> > > With the old way it is not buildable, for example, with IBM's
> > > JDK, since it relys on a `rt.jar' file being the core class jar
> > > (it isn't always). Since it can be difficult to determine an
> > > appropriate CLASSPATH programmatically, I thought having a
> > > (rather simple) extra step would be an ok price for flexibility.
> > >
> > > A CLASSPATH of ${JRE_HOME}/jre/lib/{core,rt}.jar:. should
> > > suffice; maybe it would be a good addition to set a default
> > > CLASSPATH if it hasn't been explicitly set?
> >
> > wouldn't that cause problems with jars that have to go in the
> > bootclasspath?
>
> I'm not sure what you mean, but `bootclasspath' is meaningless in
> general. Other VMs don't support things like -Xbootclasspath.

but they have some equivalent form; e.g. kissme.  have you tried using 
kissme as the VM with this new build?


cheers;
rsn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE/d+zw+e1AKnsTRiERA6F9AJ9HMcldg2wvTDLfGasHiwlOYdBsngCdEUja
yOrVrqkQxfWHeEqU+fxRa0s=
=4Zgk
-----END PGP SIGNATURE-----