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] |
> 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.