On Tue, Aug 15, 2006 at 02:42:09AM -0500, Peter Samuelson wrote: > [Michael Poole] > > On top of the default automake behavior being horribly broken, does > > that make usual revision control practices horribly broken? > > It really bothers me to hear people claim as a best practice that you > should never recompile configure.ac or Makefile.am except under > controlled conditions. To me it is a very important philosophical > point that Debian be self-hosting. That means packages should build > without error from source, not just from intermediate text files like > 'y.tab.c', 'configure', or 'Makefile.in' which, while arch-independent, > are not particularly human-editable, and certainly not source code in > the GPL sense. > > Using a provided 'configure' binary instead of building from source has > the same problem as using any other provided binary rather than > building from source. It clearly expresses a lack of confidence that > the system _is_ in fact self-hosting. It tells our users, "we will > give you all the source code, but you'd better not modify that one > configure.in source file, because we do not dare trust our tools to > build it correctly." > > So yeah, I advocate always building packages from source, and if > autoconf someday comes up with an incompatibility that causes a FTBFS > somewhere, let that be reported and fixed. Not just worked around by > trying to avoid running autoconf.
It has nothing to do with "being afraid to", but everything with "not needing to". Building and testing a C program on one architecture does not necessarily mean that it will work on another, too. Differences that exist in things such as endianness, word size, signedness of default types, and other things, may mean that a C program which works perfectly on one architecture may break on another. The same isn't true for autoconf; this is written in portable POSIX shell. If it works on one architecture, it works on all of them. The output of autotools, if done with the same version, is totally deterministic. Proper use of autotools will retain that deterministic property. "Proper use" does include things like making sure you use at least the autotools version for which your configure.ac and/or Makefile.am was written. It also includes making sure that you do not try to do things that will work on one Linux-based architecture, but will fail horribly on another. Sure, you should verify that things still work if you run autoreconf on your source tarball, but there is no real need to build autotools output files in the build target of debian/rules if all you want to do is verify that they build properly. An extra reason not to do this is that some older versions of the autotools will not run themselves as "automake-version" or "autoconf-version" or whatnot, resulting in behaviour that is not, in fact, deterministic, since if you have more than one version of the autotools installed, the default version may very well be the wrong one. Moreover, this thread, at least to me, is more about what an upstream should do rather than what a Debian developer should do; it is not good practice as an upstream to assume that anyone else than yourself will need to run the autotools on your input files on a regular basis. You should distribute the .tar.gz (and, optionally, the .tar.bz2 if you build that too), which you produce with 'make distcheck'. If you do that, everything _will_ work for everyone else, and there will not be a need to put in backwards compatibility stuff for people using older versions of autotools. If someone does want to modify the configure.ac or whatnot, it is not unreasonable to ask that they upgrade to the most recent version. Of course, you should add things like AC_PREREQ to the right input files to make that easier, but that's a different matter. -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
