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.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
