[Python-Dev] Bumping autoconf from 2.68 to 2.69 (original) (raw)

Trent Nelson trent at snakebite.org
Tue Oct 16 10:59:18 CEST 2012

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

In article <20121016071236.0792D2500FA at webabinitio.net>, "R. David Murray" <rdmurray at bitdance.com> 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 ACPREREQ(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 at acm.org

    Trent.

More information about the Python-Dev mailing list