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

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

Re: GCJ build (was Re: [GNU Crypto] MD2 hash)


From: Raif S. Naffah
Subject: Re: GCJ build (was Re: [GNU Crypto] MD2 hash)
Date: Wed, 23 Oct 2002 23:05:33 +1000
User-agent: KMail/1.4.3

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

hello Olivier,

On Tuesday 22 October 2002 22:51, Olivier LF wrote:
> Hi there,
> I finally made it to the new list!

welcome to the new list :-)


> > > | if you're referring to the top level directory, the Makefile.in
> > > | should not be there anymore (in my local CVS it is not).
> > >
> > > I meant the gcj/ ones, but isn't that build method destined to be
> > > included in the top level build?
>
> I am not sure what is best. If you leave the generated files
> (Makefile.in, configure...) under CVS then people can checkout
> gnu-crypto and compile it with minimum requirements, that is:
>
> - A shell enviroment
> - gcj 3.1 (at least)
>
> If you remove the generated files then people also need very recent
> versions of:
>
> - autoconf
> - automake
>
> If someone finds a bug with a release, I think it is nice to be able
> to say: just checkout the latest CVS and try again. It is one thing
> to ask to compile the latest, its another to ask to install autoconf
> and automake before.

that's a very good point! should we do the same for the top level 
directory too?


> > in the future may be.  i was not personally able to combine both;
> > but if somebody else is willing and have the time, then pls go
> > ahead.  i think ultimately we should have one way to build with the
> > GNU tools
>
> I have some home crafted Makefile.am that do that but I was never
> quite satisfied with the result. What happens is that as soon as the
> Makefile.am has these directives:
>
> lib_LTLIBRARIES = lib-gnu-crypto.la
>
> lib_gnu_crypto_la_LIBADD =
> lib_gnu_crypto_la_LDFLAGS = -version-info 1:0
> lib_gnu_crypto_la_SOURCES = $(crypto_sources)
>
> for the gcj shared libraries, Makefile.in includes plumbing
> for the shared libraries.
> Unfortunatly these targets have variables that "configure" must
> resolve correctly in order to produce a syntaxically correct
> Makefile.
>
> This is done by having:
>
> AM_PROG_LIBTOOL
> AM_PROG_GCJ
>
> in configure.in but it cannot be in a conditional. These steps must
> be performed to have a syntaxically correct Makefile. This is very
> anoying because, even if the user only wants a "jikes" compilation,
> "configure" has to check for libtool and other shared library
> issues...
> And worse: if it is not ok I believe it won't output a Makefile while
> all the user wanted to do was a bytecode compilation with jikes!

doesn't the user need to have LIBTOOL anyway to use the gcj/ tools? 
doesn't including the Makefile.in as you point out in the previous part 
of the message enough to address the needs for people who want to just 
compile sources?


> I don't know the way arround this.
>
> Olivier
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE9tp6d+e1AKnsTRiERA55CAKDc/OVUd6M5wN6Bojqkic4tQluRgACg7lzB
9z35AZhgdaV/MSfMt0T89CI=
=pdrd
-----END PGP SIGNATURE-----





reply via email to

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