[kaffe] Re: [GNU Crypto] Re: gnu-crypto.m4. was: new jalopy available

[Raif S. Naffah]

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

hello Dalibor,

On Mon, 24 Nov 2003 05:16 am, Dalibor Topic wrote:
> Raif S. Naffah wrote:
> > On Sat, 22 Nov 2003 10:51 am, Dalibor Topic wrote:
> >>...
> >>p.s. is there some kind of gnu-crypto.m4 file for automake to add a
> >>--with-gnu-crypto option to it? I'd love having a simple way to
> >> chuck in GNU crypto into kaffe without having to bother with those
> >> weird U.S. crypto laws, as kaffe's CVS server is located in
> >> California.
> > ...
> > things to consider are:
> >
> > * building gnu crypto is effectively building three jars/libraries:
> > one is the gnu-crypto per se (incl. the JCE Adapters), the other
> > two are javax-crypto and javax-security (callbacks and sasl).
>
> So we have three seperate jar files, right?

correct.


>... Then we need a way to put
> those in the bootclasspath of the calling VM.

i need to double check this but from memory you only need the 
javax-crypto.jar only on the bootclasspath iff kaffe exhibits the same 
behaviour as the jdk1.4; otherwise it only need to be accessible from 
the classpath (similar to any other jar).


>... The VM will need to
> figure out the location of the jar files to add to it's
> bootclasspath.
>
> Let's say we have
>
> --with-gnu-crypto[=PATH-TO-JAR-LOCATION]
>
> as an API.

yes.  if the optional PATH-TO-JAR-LOCATION is omitted, then [the | a] 
default list of destinations would be searched, incl. 
/usr/local/gnu-crypto.  (see the _GNU_CRYPTO_WITH_CLASSPATH macro 
(lines 119+ in  
<http://savannah.gnu.org/cgi-bin/viewcvs/gnu-crypto/gnu-crypto/acinclude.m4?rev=1.11&content-type=text/vnd.viewcvs-markup>).  
otherwise the designated path, and only that path, is considered.

if/when the expected jars are found in the location, the macro:

a. prints a message that it found, or not, the expected jars;
b. sets, as you suggest later the two ac variables:

   USE_GNU_CRYPTO, and
   GNU_CRYPTO_HOME (or similar).


> Maybe even a
> --with-gnu-crypto-cvs=PATH-TO-GNU-CRYPTO-CVS-CHECKOUT

i'm doubtful of the value of this since we (GNU Crypto) always build 
outside the CVS directory.  but you may have some ideas that would work 
around this situation.  if not i'd leave this "feature" to a followup 
release :-)


> API later for those among us who like building from CVS checkouts ;)
>
> So basically, I'm thinking about two APIs (macros), one for JARs, and
> another for rebuilding GNU Crpyto from CVS. I'll concentrate in the
> first, as that one seems to be easier to do as a prototype, and with
> lessons from that one, it should be easier to build the other.

agree.


> > * once installed in a location (default is /usr/local/gnu-crypto)
> > it should be straightforward to construct the different
> > options/switches needed by the kaffe build script from the contents
> > of that location.
>
> I have the following in mind:
>
> --with-gnu-crypto should set USE_GNU_CRYPTO as an autoconf variable,
> and PATH_TO_GNU_CRYPTO_JARS. Then, we can use one to check if kaffe
> should use GNU crypto, and the other to adapth the bootclasspath in
> the kaffe driver script, kaffe.in.

agree.


> > * it would be nice to be able to re-use most, if not all, of the
> > generated options/switches of such an m4 library with other VM
> > providers; e.g. kissme and jikes rvm.
>
> The options/switches depend on the options/switches from the GNU
> crypto configure.in you want the projects utilising GNU Crypto to be
> able to change. If there are any of them that make sense once you've
> uild the JAR files, we should list a set of
> --enable-gnu-crypto-something switches to allow the VM to enable
> those features.

again, the fact that we build outside the CVS directory, IMO makes it 
hard to chain build GNU Crypto with other projects.

on the other hand, i think what we have discussed so far would allow 
easy integration of GNU Crypto jars with every VM provider; i.e. once 
GNU_CRYPTO_HOME is set, and depending on the requirements of the 
specific VM, the appropriate jars can be constructed as part of the 
bootclasspath (or equivalent) and/or the plain classpath.


> > if you think this is worth it, let's continue this thread on the
> > GNU Crypto list.
>
> I've cc:ed the kaffe mailing list, as I assume kaffe will provide the
> testbed for this type of integration.

much appreciated :-)  i'll delay the release until we have this working.


> > p.s. if there is a Debian packager out there who is capable/willing
> > to help us deliver the library as a debian package, pls. let me
> > know.
>
> Wasn't Morgon Kanter working on that? [1] What happened to that
> effort?

a recent email sent almost two weeks ago is still unanswered, so i 
presume per is busy with something else.


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

iD4DBQE/wb2c+e1AKnsTRiERAy3qAJiIIFGUhIS3u/U3BzRd3cJ5tp47AJ9lKNLW
HdUVr6UMe3zB1WMkMCeBow==
=NqiN
-----END PGP SIGNATURE-----