Re: CVS Guile and configure, Makefile.in, and other auxiliary files...

[Lars J. Aas]

On Wed, Oct 04, 2000 at 09:10:39PM +0200, Marius Vollmer wrote:
: "Lars J. Aas" <address@hidden> writes:
: 
: > I'd like to try out Guile from the CVS repository.  Because I'm
: > mostly doing work with Autoconf 2.49b (CVS), Automake 1.4a (CVS),
: > I've scrapped the older, buggier, less portable versions of those
: > tools...  This makes it of course impossible to bootstrap the
: > Guile CVS repository.
: 
: Why?  Are there bugs in our configure stuff?

I won't call it bugs - lets just say that CVS Autoconf and Automake haven't
managed to stay backwards compatible:

| [nfs] guile-core > ./autogen.sh 
| configure.in:119: warning: AC_C_CONST was called before AC_PROG_CC_STDC
| configure.in:306: error: AC_LANG: unknown language: 
| configure.in: 117: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' 
instead
| automake: configure.in: installing `./install-sh'
| automake: configure.in: installing `./mkinstalldirs'
| automake: configure.in: installing `./missing'
| automake: configure.in: installing `libguile/depcomp'
| libguile/Makefile.am:102: invalid unused variable name: `OMIT_DEPENDENCIES'
| qt/Makefile.am:39: invalid unused variable name: `OMIT_DEPENDENCIES'
| doc/Makefile.am:21: installing `doc/mdate-sh'
| guile-readline...
| configure.in: 8: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' instead
| automake: configure.in: installing `../depcomp'
| [nfs] guile-core > automake --version
| automake (GNU automake) 1.4a
[...]
| [nfs] guile-core > autoconf --version
| autoconf (GNU autoconf) 2.49b
[...]
| [nfs] guile-core > libtool --version
| ltmain.sh (GNU libtool) 1.3.5 (1.385.2.206 2000/05/27 11:12:27)
| [nfs] guile-core > 

: > Is there a very strong reason for not adding the auto-generated
: > files to the Guile repository?
: 
: I don't think the reason is very strong.  For a while, we had the
: created files checked in, but now we don't mostly due to my urging.
: 
: I think that checking generated files into CVS causes more annoyances
: for the developers than it solves.  In effect it requires every one to
: have the exact same set of auto* tools in use for Guile.

Not everyone - only the maintainers commit'ing build-related changes to
the CVS repository.

: This might not be a bad thing, incidentally, but it is also a obstacle.

I agree that it would be best if people could use the auto* tool versions
of their choice when working with Guile, but since that does not work, as
demonstrated above, that goal has not been achieved by removing the
autogenerated files from the repository.  What it does achieve is to force
me to keep multiple installations of the auto* tools if I want to use Guile
from CVS.  So I am delaying using Guile from CVS for the moment...

  Lars J