gnu-crypto-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Casey Marshall
Subject: Re: address@hidden: Re: [GNU Crypto] new make plumbing]
Date: Sun, 28 Sep 2003 08:54:45 -0700
User-agent: Mutt/1.4i

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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:
> > On Sun, Sep 28, 2003 at 01:54:28PM +1000, Raif S. Naffah wrote:
> > > hello Casey,
> > >
> > > in the old days, i used to do the following for building a
> > > non-gcj-friendly distro:
> > >
> > > address@hidden gnu-crypto]$ cd ../../build-no-gcj
> > > address@hidden build-no-gcj]$ rm -rf *
> > > address@hidden build-no-gcj]$ ../../workspace/cvs/gnu-crypto/init.sh
> > > address@hidden build-no-gcj]$ ./configure --with-jikes
> > > address@hidden build-no-gcj]$ make
> > >
> > > how can i have the same with the new mechanism?  doing
> >
> > 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.

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.

> > 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.

- -- 
Casey Marshall || address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/dwQpgAuWMgRGsWsRAlBGAJ0aHbH1UeNqTi2WYZBk+LMdop9ukwCeOsZx
7O5B0sgxBNv8Xw+Z6RLDV9o=
=0iDz
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]