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

[Raif S. Naffah]

=2D----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=20
javax-crypto.jar only on the bootclasspath iff kaffe exhibits the same=20
behaviour as the jdk1.4; otherwise it only need to be accessible from=20
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[=3DPATH-TO-JAR-LOCATION]
>
> as an API.

yes.  if the optional PATH-TO-JAR-LOCATION is omitted, then [the | a]=20
default list of destinations would be searched, incl.=20
/usr/local/gnu-crypto.  (see the _GNU_CRYPTO_WITH_CLASSPATH macro=20
(lines 119+ in =20
<http://savannah.gnu.org/cgi-bin/viewcvs/gnu-crypto/gnu-crypto/acinclude.m4=
?rev=3D1.11&content-type=3Dtext/vnd.viewcvs-markup>). =20
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=3DPATH-TO-GNU-CRYPTO-CVS-CHECKOUT

i'm doubtful of the value of this since we (GNU Crypto) always build=20
outside the CVS directory.  but you may have some ideas that would work=20
around this situation.  if not i'd leave this "feature" to a followup=20
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=20
hard to chain build GNU Crypto with other projects.

on the other hand, i think what we have discussed so far would allow=20
easy integration of GNU Crypto jars with every VM provider; i.e. once=20
GNU_CRYPTO_HOME is set, and depending on the requirements of the=20
specific VM, the appropriate jars can be constructed as part of the=20
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=20
presume per is busy with something else.


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

iD4DBQE/wb2c+e1AKnsTRiERAy3qAJiIIFGUhIS3u/U3BzRd3cJ5tp47AJ9lKNLW
HdUVr6UMe3zB1WMkMCeBow=3D=3D
=3DNqiN
=2D----END PGP SIGNATURE-----