On Tue, 2009-07-07 at 07:14 -0400, Sam Varshavchik wrote:
> libguestfs is a case in point - the Debian maintainer builds it
from
> git using some unknown version of autoconf, and I build it on RHEL and
This is a rare exception.
No, it's a rare exception for project to keep autotools generated files
in version control.
Yet people still build lots of projects from version control on a
variety of different distros using different versions of autotools.
I'm also making the point that maintainers build tarballs without paying
much attention to the versions of autotools they're using.
For each project you can cite that releases their
sources this way, I'll be happy to cite twenty others who don't.
Feel free to come up with your largest list. I'll just go through
Sourceforge, and grab the first x*20 projects, in response.
Please tone down the hyperbole.
I'd be very interested to hear of a specific case where a recent
autotools update has broken old tarball builds. If that was in fact
common, and we had some examples, I'd agree with you.
Given that automake's "make dist" automatically rolls
Makefile.in, and
configure into the tarball (together with a bunch of other stuff), one has
to go out of their way to leave them out of the tarball.
Yes, that autotools generated files are distributed in tarballs is a
clear autotools design decision. But why? Is it:
a) because the autotools maintainers feel it is unreliable to have
people building from the tarball to re-run autotools or
b) because the autotools maintainers feel it is inconvenient to
require people build from tarballs to have autotools installed
I suspect (b) is primary reason, especially in recent times.
Cheers,
Mark.