[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patches to README-release
From: |
Jim Meyering |
Subject: |
Re: Patches to README-release |
Date: |
Sat, 28 Jan 2012 09:27:39 +0100 |
Gary V. Vaughan wrote:
> Hi Jim,
>
> On 28 ม.ค. 2012, at 1:21, Jim Meyering <address@hidden> wrote:
>
> Reuben Thomas wrote:
>
> Ping? The patches still apply cleanly to HEAD.
>
> On 22 December 2011 19:54, Reuben Thomas <address@hidden> wrote:
>
> -* Ensure that the desired versions of autoconf, automake, etc.
>
> - are in your PATH. See the buildreq list in bootstrap.conf for
>
> - the complete list.
>
> That paragraph is trying to say that one should be careful not to
> prepare a release using anything less than the latest stable releases.
> That is *not* checked by running bootstrap, and hence why I mentioned
> it here. For example, if I have a working directory with lib/getdate.c
> generated from before the preceding bison release, I should be careful
> to remove it (make maintainer-clean) and regenerate it with the newer
> version of bison. In this case, "make distclean" is insufficient.
>
> I.e., you're welcome to reword it, but not to remove it altogether.
>
> How about:
>
> If you have not yet upgraded to saner bootstrap, which check autotools
> versions automatically for you, then you'll need to make a painstaking
> manual check of the autotools versions in your PATH every time you
> want to make a new distribution tarball.
You have missed the point.
When I make a release, I want to use at least the latest stable
build tools. AC_PREREQ does not necessarily encode that requirement.
> <evil grin>
>
> More succinctly: Does gnulib bootstrap deliberately not consider the
> AC_PREREQ and friends versions as full and correct autotool version
> bootstrap prerequisites for good reason? Or is that a bug forcing the
> addition of this paragraph in README-release, which Reuben has
> correctly noted as spurious (when using saner bootstrap)?
While the AC_PREREQ for coreutils says 2.64, I do not want to distribute
a tarball built with an autoconf that old. I use autoconf 2.68+
The "2.64" is for nominal correctness (if you use 2.63, you'll hit
known bugs). There have obviously been bug fixes in autoconf in
the 2.5 years since then, but I don't have evidence that coreutils
would have problems with files generated by 2.64 or newer.