This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: CVS and configure



> Juergen> Now, this seems to imply that it is a *very* bad idea to put
> Juergen> generated files in CVS...

This is a frequently asked question.  It's a controversial choice, but
I think it's still the right one.

The problem is that the tools (autoconf, autoheader, automake,
aclocal, and libtool) are not really independent of the source files.
Strictly speaking, for a given set of Guile sources, there is only one
set of tool versions that will process it correctly.  Guile's README
file specifies the required versions of the tools; these are the
versions that the Guile developers themselves ought to be using.

So when Christian says:

> Not really. It merely demonstrates that one should not mix generated
> files from the CVS with locally regenerated files.

I wince a bit; everyone should be able to regenerate files on their
own, and have things work.  Otherwise, we're not providing people with
all the `sources' they need; in order to be a developer, you would
need "secret" versions of the tools.  I think that kind of segregation
is really bad, and contrary to the spirit of Free software.

So, I'd restate: one should not mix generated files from Guile's CVS
repository with files regenerated using different revisions of the
tools.  Always use the tool versions specified in README.

For my day job, I need to use bleeding edge versions of the tools, so
I use the following shell function, to make sure I run the tools from
a special directory that contains the right versions for Guile.

function autoguile {
  [ -f GUILE-VERSION ] || {
    echo 'Run autoguile at the top of a Guile working tree.' >&2
    return 1
  }
  (
    PATH=/calvin/jimb/guile/sun4u/bin:$PATH
    set -x -e
    cp guile.m4 qthreads.m4 /calvin/jimb/guile/sun4u/share/aclocal
    aclocal
    automake
    autoconf
    set +x +e
  )
}


It's reasonable to ask why this issue comes up with the tools
mentioned, and not with GCC, etc.  The answer is that those tools are
young, and relatively unstable; if the C language were evolving as
fast as automake, etc., we might need to specify the compiler
revision, too.  For example, C++ has been changing a lot the last few
years; I'll bet you see people specifying exactly which C++ compiler
to use for their sources pretty frequently.