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

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

Re: [GNU Crypto] Questions for release of version 2


From: Raif S. Naffah
Subject: Re: [GNU Crypto] Questions for release of version 2
Date: Mon, 16 Jun 2003 19:39:49 +1000
User-agent: KMail/1.5.1

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

On Mon, 16 Jun 2003 07:36 am, Morgon Kanter wrote:
> > > 1) Is this accompanied by a change in the shared libs soname (to
> > > .2)?
> >
> > yes.  once you checkout the CVS, you'll notice the Makefiles (and
> > the ANT build.xml) reflect this move.  also, the deliverables
> > contain two optional libraries: javax.crypto and javax.security. 
> > these will be at version 1.0.  the Makefiles in both jce and
> > security subfolders also reflect that fact.
>
> Hrm, alright.
>
> > i suggest you have a look at the current make process for
> > suggestions on where/how to place these.
> >
> > we build the libraries in three different ways.  one that is
> > GCJ-friendly (incl. the shared libraries, and this is the primary
> > target for the exercise).  one that is not GCJ-friendly, i.e. just
> > using GNU toolchain to compile, build, test and exercise the
> > library and its tools.  and last a pure-java way through Apache
> > ANT.  the first two require copying the source to a build
> > destination --the init.sh scripts in the toplevel and under the gcj
> > directory prepare the sources for the build process.
>
> I think that for the Debian package, we should use the first way and
> the first way only.

ok.

>... This does everything we want to accomplish
> already (build the shared/static libraries and jar files, tests,
> etc). This essentially keeps the build-depends down to a minimum (all
> we need is gcj, and it allows it to go into Debian's main archive
> (ANT itself is in contrib, if we build-depend'ed on ANT, gnu-crypto
> would have to go into contrib).

agreed.


> The bit that worries me is the fact that we have to create a seperate
> build directory in order to do this -- I've never seen a debian
> package do this, and what I've tried to make it work hasn't worked
> so far. However, I'm sure there is a way to make it work with the
> seperate build directory. Can you run gcj/init.sh from the top of
> the source tree and then build? (I'd try it myself, but I already
> have a build of gnu-crypto going, and it takes a _very_ long time
> :p).

the current build process is based on original contribution by Olivier 
Louchart-Fletcher for the GCJ-friendly version.  since then it has been 
changed, to closely resemble, as close as possible, the non 
GCJ-friendly one.  the only differences are now not in the process of 
steps involved but rather what version of files get copied --and used-- 
in the build directory.  the rationale is:

* configuring and making is usually done in a separate build directory; 
e.g. GCC and GCJ.
* for compiling, linking and generating the shared library some specific 
version of libtool and friends are used (those in the gcj directory).
* some algorithms (e.g. Serpent) have the java sources generated by m4 
macros.  the ultimate source files for those algorithms end up 
overwriting their pure-java versions found under source in the 
toplevel.

if you think you need to change that because it would make building a 
debian package easier, i'm happy to look into this possibility, 
provided it does not make building and/or maintaining the rest more 
difficult.


> I figure that there should be 5 packages. Stuff means things like
> shared libraries, ar archives, and jar files.
> libgnu-crypto2-java -- contains the gnu.crypto stuff
> libgnu-crypto-jce1-java -- contains the javax.security stuff
> libgnu-crypto2-doc -- contains javadoc etc. for gnu.crypto
> libgnu-crypto-jce1-doc -- contains the javadoc etc. for
> javax.security libgnu-crypto2-programs -- contains the entropy and
> speed testers, etc.

how are the javax.security.sasl and javax.security.auth.callback 
packaged?  if in javax.security above, any reason why not calling them 
libgnu-crypto-security1 or libgnu-crypto-sasl1?


> Obviously, because this is java, -dev packages aren't needed
>
> That's all my random thoughts for now.
> Morgon

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

iD8DBQE+7ZBm+e1AKnsTRiERAzhNAJ4nFAmdBiR5aicjpUQC5g7Eowe86QCgjTni
j0w5dMGaSmK65qc91WEj0UI=
=kFXP
-----END PGP SIGNATURE-----





reply via email to

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