I do not think we should require individual developers committing changes to configure.ac to use a particular version of autoconf when regenerating configure. That is a burden.

The solution to your problem is to maintain your patches _only_ against configure.ac and rerun autoconf using whatever version you need yourself.

If a release manager decides they want configure generated with a specific version of autoconf at release time, they should rerun that specific version of autoconf and commit the result _for the release_.

otherwise the checked in configure script exists entirely as a convenience.  configure.ac is always the source of truth.

-gps

On Tue, Nov 22, 2016 at 11:38 PM Xavier de Gaye <xdegaye@gmail.com> wrote:
On 11/22/2016 08:16 PM, Ned Deily wrote:
 > On Nov 22, 2016, at 11:06, Xavier de Gaye <xdegaye@gmail.com> wrote:
 >> The configure file on the default and 3.6 branches have been generated
 >> with autoconf 2.70 once again. This is annoying when you have to
 >> maintain patches to this configure file in order to build on a non
 >> supported platform.
 >
 > I'm sorry about that.  I did promise to rerun with autoconf 2.69 before tagging the release so committers didn't have to worry about it but I didn't notice my note to do so until after 3.6.0b4 had
already been tagged.  I'll try to do better for rc1.
 >
 > Perhaps another solution to the problem might be to not include the autoconf-generated changes in the patches and just always run autoconf before doing a build?  That's what we suggest for patches
submitted to the tracker.
 >
 > And this might also be a candidate for handling in our upcoming new development workflow, i.e. something like having autoconf automatically be run as part of checkins.  If it hasn't already been
discussed there, it might be worth bringing up on the core-workflow mailing list.
 >
 > --
 >   Ned Deily
 >   nad@python.org -- []
 >

 From the configure logs since last july, it seems that Benjamin and Serhiy are
the only one using autoconf 2.70:

     changeset 102530:b04560c3ce69 - author Benjamin Peterson
     changeset 103648:816ae3abd928 - author Serhiy Storchaka

If it is not too difficult to build autoconf 2.69 from source, then the
solution could be that they switch to autoconf 2.69.

Xavier
_______________________________________________
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/