[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: an update to automake-1.11?

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]