Re: [GNU Crypto] Re: GCJ build

[Raif S. Naffah]

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

On Saturday 26 October 2002 19:04, Olivier LF wrote:
> On Sat, Oct 26, 2002 at 09:15:50AM +1000, Raif S. Naffah wrote:
> > ...if somebody wants to hack the code, is it fair
> > to require them to have the GNU tool chain installed (automake,
> > autoconf, libtool)? if they are not familiar with how the GNU build
> > system works, then ANT should be enough for them.
>
> Hackers will never have a problem. Most of the time they'll have the
> right software already installed anyway.

ok.


> Testers will have more issues...Each extra
> requirement to build the software cuts in half the pool of potential
> testers.

but what is that piece, or pieces of software that testers may not have 
already?  they have to have libtool installed, otherwise they wouldnt 
be able to generate the shared library. right?

we're then left with automake and autoconf.  but are we really?

if we look at what is needed to build and test the library, if/when the 
included gnu-crypto.jar is not enough, we find that we need:

1. a JUnit distribution,
2. a java bytecode compiler:
   a. jikes,
   b. sun's javac, or
   c. GCJ >= 3.1,
3. the sun's java interpreter,
   or not if will be generating/using gnu-crypto.so
4. the sun's javadoc tool, and
5. a build system/toolchain:
   a. jakarta ant, or
   b. GNU automake, autoconf, libtool.

* there are lots of pieces of software that contributors will need to 
install/have to contribute.
* to build GCJ contributors need to have the auto* tools.
* to use an open source VM; e.g. Kissme, and the runtime classes that go 
with it, contributors need to have the auto* tools.

the interesting thing to note here is that any GNU library/tool required 
in conjunction with GNU Crypto, already requires what we are debating 
whether to include or not to include in the list of pre-requisites.

in other words, requiring automake+autoconf will not be the cause of 
more losses to potential testers.


> The generated files are, well... generated. It is simple to automate
> their generation as well as the associated CVS commit.

sure.  and including them in the deliverables, etc.  all this can be 
automated.  if we have to then we will.


> > if the above makes sense, and we do not want to over burden
> > ourselves maintaining stuff that is generated by the tools anyway
> > (and eliminate the need for including such files in the
> > deliverables), may be we should make the build rely/use the auto*
> > magic, even with the gcj/ alternative.
>
> I am not sure if I understand that one. Are you saying that even
> releases should have the dependency on autotools? That would be very
> unconventional.

yes i am saying that the release would rely on the auto* tools to build, 
if the user (a) is not happy using the gnu-crypto.jar from the 
distribution, or (b) wants to build gnu-crypto.so.

building GCJ, Classpath, and Kissme, all require the auto* tools.  if we 
will be unconventional, we will be in good company :-)


> About your previous post:
>
> if USE_GCJ
> ...
> ...
>
>
> yes, Makefile.in includes new targets outside the conditional!
> and you get broken Makefiles without the "configure" check for
> libtool/shared libraries stuff.

noted.

what we have today (ant + 2 * make) does then address the current 
problem you described earlier --of the Makefile.in not including 
reasonable defaults that would not break a configure on a machine that 
does not have libtool etc. installed.

another consequence is that, we shouldnt try to integrate both make 
processes into one, until that constraint/problem is lifted/solved.

would the maintainer(s) of the auto* tools be able to help us with this 
issue?


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

iD8DBQE9u9Yo+e1AKnsTRiERAwWQAJ9jbZzkEnNxRWthm6RZLvgpah2eugCcDgVy
tqdN51wEE5Rq7GJFSaTvI+I=
=3r2o
-----END PGP SIGNATURE-----