On Tue, Oct 16, 2012 at 01:04:46AM -0700, Ned Deily wrote:
> In article <20121016071236.0792d250...@webabinitio.net>,
>  "R. David Murray" <rdmur...@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 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,
>  n...@acm.org

        Trent.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to