guile-devel
[Top][All Lists]
Advanced

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

Re: building guile from CVS


From: Marius Vollmer
Subject: Re: building guile from CVS
Date: Fri, 21 Jan 2005 15:06:42 +0100
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux)

Bruno Haible <address@hidden> writes:

> Configuring guile-core from CVS so that it builds requires a wizard.
> Although I can claim to be an old autoconf and automake user, I needed
> two hours and the help from Kevin Ryde to get it running.

I can feel your pain. :-]

Yes, getting Guile to compile from a fresh CVS checkout is not as easy
as it can be.  But I wouldn't put all the blame on Guile.  Guile
doesn't do anything out of the ordinary, as far as I am aware (now
that we have dropped our own version libltdl), but the autotools still
have trouble with it.  For example, when no installed libltdl is
found, Guile builds its own in the way that libtool prescribes it, but
then libtool can't find the freshly build libltdl when we run the
freshly build guile executable during the build.[1]

There _is_ a big bug in Guile tho (courtesy myself): when checking out
guile-core, there is no documentation on how to proceed.  These docs
are in the file HACKING, but that file is hidden deeply in the
guile/workbook module.  Not good.  I have added a README.CVS file to
CVS.  Also HACKING didn't talk about the guile-scripts and workbook
modules that you need as well in order to build guile-core.  I fixed
that as well.

If that was the source of your frustration, please accept my sincere
apologies.

> Therefore I'd suggest that you add some instructions to guile-core/autogen.sh
> so that it does become so extremely frustrating to attempt to build guile.

Why do you want to add instructions to autogen.sh that contradict what
autogen.sh is doing itself?  Shouldn't we fix autogen.sh, preferably?

> # 2) Use these commands to update guile-core:
> #    $LIBTOOL_PREFIX/bin/libtoolize --force --copy --ltdl
> #    cp $LIBTOOL_PREFIX/share/aclocal/libtool.m4 guile-config/libtool.m4

I don't want to make Guile more complicated by catering to what could
be called 'broken' installations of libtool, etc.  If libtoolize is
not in the path and libtool.m4 is not found by aclocal, then the
installation of libtool is 'broken'.  You might bitch that it is too
complicated to install libtool correctly, and you are probably right,
but hey, I at least don't care. ;-)

> #    aclocal -I guile-config

There are no files in guile-config that are needed by aclocal (except
those that you have copied there in step 2.)

> #    autoconf
> #    autoheader && touch config.h.in
> #    automake -a

Isn't autoreconf supposed to do this?  If it doesn't, it's a bug in
autoreconf, right?


So, when there are bugs in how we use the autotools, we should of
course fix them.  If there are simple workarounds for bugs in the
latest released versions of the autotools, we should use them as well.
But adding instructions to autogen.sh to do manually what autogen.sh
is supposed to do automatically is not going to help much, I'm afraid.


[1] Hmm, maybe this has something to do with cross-compilation magic
that we don't do properly...




reply via email to

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