On Tue, Oct 16, 2012 at 12:12:35AM -0700, R. David Murray wrote:

On Mon, 15 Oct 2012 23:18:04 -0700, Ned Deily wrote:

...

In article <20121016043352.GA21441@snakebite.org>, Trent Nelson wrote:

...

Any objections to regenerating configure with autoconf 2.69? The current version is based off 2.68, which was release on the 22nd of September 2010. 2.69 was released on the 24th of April, 2012.

(There are some fixes for the more esoteric UNIX platforms that Snakebite will benefit from. Also, I struggled to find a box with 2.68 even installed when I needed to regenerate configure this weekend; it seems all package management/ports have bumped to 2.69.)

If there are no objections, can it be applied across the board? 2.7, 3.2, 3.3 and 3.x?

I believe it is the case that we don't currently require a specific version of autoconf. autoconf is only run when making a committer makes a change to configure.ac et al and then it is run on the committer's machine. So whatever is checked in for those files reflects the version of autoconf that the committer used.

My understanding is that we use a specific version of autoconf. The reason is that otherwise we end up with useless churn in the repo as the generated file changes when different committers use different versions.

Indeed; the 2.68->2.69 bump results in a 746 line diff for configure.

In the past we have had issues with a new autoconf version actually breaking the Python build, so we also need to test a new version before switching to it.

If there are no objections in principle to the bump (i.e. nobody is aware of any existing 2.69 incompatibilities), my plan is to bump, then make sure all the build slaves and Snakebite machines work with the new version. If 2.69 introduces insurmountable build issues, I'll simply revert back to 2.68 (with some notes at the top of configure.ac mentioning the issues with 2.69). Trent.

On Tue, Oct 16, 2012 at 01:04:46AM -0700, Ned Deily wrote:

In article <20121016071236.0792D2500FA@webabinitio.net>, "R. David Murray" wrote:

...

My understanding is that we use a specific version of autoconf. The reason is that otherwise we end up with useless churn in the repo as the generated file changes when different committers use different versions. In the past we have had issues with a new autoconf version actually breaking the Python build, so we also need to test a new version before switching to it.

Well, there was a test in the past for a specific version of autoconf but I believe that was removed. I see that the default branch configure.ac contains AC_PREREQ(2.65) but the most recently checked-in version of configure was generated with 2.68.

That's a good point regarding AC_PREREQ. I think there's been a general unspoken rule to try and minimize 'configure' churn, which means using the same version of autoconf that the previous person used.

I understand about the desirability of avoiding a lot of churn although it seems to me to not be a huge thing;

I don't know, the churn is usually offensive enough to warrant using the same autoconf version. It's impossible to vet a configure.ac change if you're regenerating configure with a different version of autoconf.

build breaking is another matter, of course. If we are going to mandate a specific version again, that should be documented and checked for.

My preference: bump to 2.69 and set AC_PREREQ(2.69). If 2.69 proves unworkable, revert back to 2.68 and AC_PREREQ(2.68). I definitely like the idea of explicitly setting the version being used via AC_PREREQ, as this will prevent accidental version churn being checked in by a committer inadvertently.

-- Ned Deily, nad@acm.org

Trent.

My understanding is that we use a specific version of autoconf. The reason is that otherwise we end up with useless churn in the repo as the generated file changes when different committers use different versions. In the past we have had issues with a new autoconf version actually breaking the Python build, so we also need to test a new version before switching to it.

Well, so I guess all committers will have to use the same Linux/FreeBSD/whatever distribution then? AFAICT there's no requirement regarding the mercurial version used by committers either. Charles

It should be sufficient to install autoconf-x.y into /home/user/bin or something similar. Installing autoconf from source really takes about 3 minutes.

Well, maybe, maybe not. autoconf depends on a least m4 and Perl, and you may very well have a compatibility issue here. That's why most distributions have package managers, and in 2012 we're past the './configure && make && make install".

It doesn't matter which OS or Mercurial version a developer uses as they don't implicitly affect any versioned resources; autoconf does.

If you're worried about the noise in diff, it's never been a problem at least to me (just don't post a configure diff for review, the configure.ac is enough). If you're worried about runtime compatibility, then autoconf is not your only worry. Proper build also depends on the target shell, target toolchain (gcc, libc, etc).

On Oct 16, 2012, at 05:32 AM, Trent Nelson wrote:

Anyway, back to the original question: does anyone know of reasons we shouldn't bump to 2.69? Any known incompatibilities?

There will be problems building with 2.69 on Ubuntus older than 12.10, and Debians older than wheezy. % rmadison autoconf autoconf | 2.61-4 | hardy | source, all autoconf | 2.65-3ubuntu1 | lucid | source, all autoconf | 2.67-2ubuntu1 | natty | source, all autoconf | 2.68-1ubuntu1 | oneiric | source, all autoconf | 2.68-1ubuntu2 | precise | source, all autoconf | 2.69-1ubuntu1 | quantal | source, all % rmadison -u debian autoconf autoconf | 2.67-2 | squeeze | source, all autoconf | 2.69-1 | wheezy | source, all autoconf | 2.69-1 | sid | source, all FWIW, precise is Ubuntu 12.04 LTS, so it carries Python 2.7 and 3.2. I think it would be fine to update the default branch (i.e. 3.4), but I'm not sure what benefit you gain from making this change to stable branches, and you could potentially cause build problems, which you may not find out about for a while, e.g. when 2.7.4 is released and all the distros go to update. Cheers, -Barry

On Tue, Oct 16, 2012 at 11:18 AM, Tres Seaver wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 10/16/2012 09:47 AM, Barry Warsaw wrote:

...

On Oct 16, 2012, at 05:32 AM, Trent Nelson wrote:

...

Anyway, back to the original question: does anyone know of reasons we shouldn't bump to 2.69? Any known incompatibilities?

There will be problems building with 2.69 on Ubuntus older than 12.10, and Debians older than wheezy.

% rmadison autoconf autoconf | 2.61-4 | hardy | source, all autoconf | 2.65-3ubuntu1 | lucid | source, all autoconf | 2.67-2ubuntu1 | natty | source, all autoconf | 2.68-1ubuntu1 | oneiric | source, all autoconf | 2.68-1ubuntu2 | precise | source, all autoconf | 2.69-1ubuntu1 | quantal | source, all % rmadison -u debian autoconf autoconf | 2.67-2 | squeeze | source, all autoconf | 2.69-1 | wheezy | source, all autoconf | 2.69-1 | sid | source, all

FWIW, precise is Ubuntu 12.04 LTS, so it carries Python 2.7 and 3.2. I think it would be fine to update the default branch (i.e. 3.4), but I'm not sure what benefit you gain from making this change to stable branches, and you could potentially cause build problems, which you may not find out about for a while, e.g. when 2.7.4 is released and all the distros go to update.

Agreed: this is really the same issue as bumping the VisualStudio version (or any other build tooling) inside a release line: too much potential for breakage for little gain.

I think Barry's suggestion of updating default and leaving stable versions alone is a good one.

On Tue, 2012-10-16 at 10:59 +0200, Stefan Krah wrote:

Charles-François Natali wrote:

...

Well, so I guess all committers will have to use the same Linux/FreeBSD/whatever distribution then? AFAICT there's no requirement regarding the mercurial version used by committers either.

It should be sufficient to install autoconf-x.y into /home/user/bin or something similar. Installing autoconf from source really takes about 3 minutes. FWIW this was also documented in the devguide, as of: http://hg.python.org/devguide/rev/5432be4d4e1a

though that description was then removed in: http://hg.python.org/devguide/rev/27be97280cff

On Tue, Oct 16, 2012 at 01:43:37AM -0700, Charles-François Natali wrote:

...

My understanding is that we use a specific version of autoconf. The reason is that otherwise we end up with useless churn in the repo as the generated file changes when different committers use different versions. In the past we have had issues with a new autoconf version actually breaking the Python build, so we also need to test a new version before switching to it.

Well, so I guess all committers will have to use the same Linux/FreeBSD/whatever distribution then? AFAICT there's no requirement regarding the mercurial version used by committers either.

Autoconf is a special case though. Different versions of autoconf produce wildly different outputs for 'configure', making it impossible to vet configure.ac changes by reviewing the configure diff. It doesn't matter which OS or Mercurial version a developer uses as they don't implicitly affect any versioned resources; autoconf does. Trent.

On Tue, Oct 16, 2012 at 11:27:24AM +0200, Antoine Pitrou wrote:

On Tue, 16 Oct 2012 05:05:23 -0400 Trent Nelson wrote:

...

On Tue, Oct 16, 2012 at 01:43:37AM -0700, Charles-François Natali wrote:

...

...

My understanding is that we use a specific version of autoconf. The reason is that otherwise we end up with useless churn in the repo as the generated file changes when different committers use different versions. In the past we have had issues with a new autoconf version actually breaking the Python build, so we also need to test a new version before switching to it.

Well, so I guess all committers will have to use the same Linux/FreeBSD/whatever distribution then? AFAICT there's no requirement regarding the mercurial version used by committers either.

Autoconf is a special case though. Different versions of autoconf produce wildly different outputs for 'configure', making it impossible to vet configure.ac changes by reviewing the configure diff.

Isn't it enough to review the configure.ac diff?

That's the ideal but it's been wrong in the past and may possibly be wrong in the future as well. Anecdotally, in the Linux distribution I package for we have a conversation about whether we should apply patches to configure.ac and then run autoreconf (or equivalent) or include the patches to ocnfigure about once a year. Although the latter has been pretty stable for several autoconf version updates enough people have bad memories of those times when bumping autoconf revisions that there's always a vocal contingent who advocate shipping patches to the actual configure scripts (they're under the impression the package maintainer will actually audit the configure patch that autoconf generated to see if there's breakage that way). -Toshio