Wouter Verhelst writes: >> In my experience, this is greatly exacerbated and perhaps even >> primarily due to older versions of autotools encouraging or requiring >> behavior that later versions of autotools declare to be broken. > [...] >> The situation is not helped when these mutually incompatible programs >> all prefer to be called "automake" or "autoconf" and, on less helpful >> distributions, do not install themselves as automake-1.9 (etc). > > Why should that matter at all? > > Autotools are tools for the upstream developer, and have had features to > declare what version the configure.ac or Makefile.am files are supposed > to be used with for quite some time now. You distribute a package that > is already autotooled; the person who compiles the software doesn't need > autotools. > > In case they do, your way of using autotools is horribly broken.
This means the default operation of automake is horribly broken. (See the lengthy comment in /usr/share/doc/autotools-dev/README.Debian.gz on AM_MAINTAINER_MODE if its problems slipped your mind.) The usual way for people to use version control is to keep the source, and provide scripts as appropriate to derive the program. Because of this, it is not common to put aclocal.m4, configure, or the other generated files into version control. Thus, anyone who downloads software from version control must run aclocal, autoheader, automake, autoconf, possibly libtool, etc. This is when backwards incompatible changes cause problems. On top of the default automake behavior being horribly broken, does that make usual revision control practices horribly broken? Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
