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.