an update to automake-1.11?

Mark McLoughlin markmc at redhat.com
Tue Jul 7 11:34:21 UTC 2009


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.




More information about the devel mailing list