http://www.python.org/dev/faq/ doesn't seem to explain how to regenerate "configure"
Here's an attempt at answering that question; I hope the following is appropriate and factually correct:

How to regenerate the "configure" script (e.g. to add a new configuration parameter)

Python's "configure" script is generated from "configure.in" from autoconf.  Do not edit "configure"; instead, edit "configure.in" and run "autoreconf".  You should run "./configure --help" to verify that your changes are documented as expected.

Python's "configure.in" script typically requires a specific version of autoconf.  At the moment, this reads:
    version_required(2.61)

If the system copy of autoconf does not match this version, you will need to install your own copy of autoconf and use this.
1. Go to http://ftp.gnu.org/gnu/autoconf/ and download the version of autoconf matching the one in configure.in
   For example:
       $ wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.61.tar.bz2
2. Unpack the tarball:
       $ tar -jxf autoconf-2.61.tar.bz2 
3. Build the specified version of autoconf and install it to a writable location (e.g. within your home directory):
$ pushd autoconf-2.61.tar.bz2
$ ./configure --prefix=$HOME/autoconf-2.6.1
$ make ; make install

This drops a copy of the appropriate version of autoconf into ~/autoconf-2.6.1

4. Go back to the python source and rerun autoconf, pointing PATH at the specific copy of autoconf:
   $ popd
   $ PATH=~/autoconf-2.6.1/bin:$PATH autoreconf

5. "autoconf" should now have updated your local copy of "configure" to reflect your changes.

6. Run "./configure --help" to verify that your changes have been applied

This looks good!  Is it worth mentioning that autoreconf updates pyconfig.h.in as well as configure?

There's also an OS X oddity to be aware of, though I'm not sure whether it's worth mentioning in the FAQ.  On OS X 10.6, the system autoconf (/usr/bin/autoconf) *appears* at first sight to be autoconf 2.61 (e.g., using autoconf --version), but has actually been modified slightly by Apple:  it produces a whole bunch of

-rm -f conftest*
+rm -f -r conftest*

differences in the generated configure file.  I don't know how much this really matters---it can make checkins look a bit confusing at times but seems otherwise harmless.  But I've been sticking to GNU autoconf 2.61 and avoiding the Apple version for this reason.

Nitpick: Various occurrences of 2.6.1 in the above should probably be 2.61.

Isn't it true that after regenerating configure that you need to check it back in? Or is that so obvious to everyone except me that it's not worth mentioning?

Eric:  interesting point.  Without having thought about it, I was assuming this was about regenerating configure and pyconfig.h.in in your own working copy (e.g., because you want to test locally some configure script changes) rather than regenerating the configure script in the central repository.

Eric Smith:
> Isn't it true that after regenerating configure that you need to check 
> it back in? Or is that so obvious to everyone except me that it's not 
> worth mentioning?
FWIW the above point wasn't obvious to me; if that's the case, then it needs to be spelled out.

My perspective here is as a developer without commit rights to svn; I'm developing patches to be attached to the issue tracker, and occasionally they require changing configure.in

BTW, should the changes to the generated "configure" be excluded from such patches, or should they be included? (to what extent do they contain meaningful information during review?)

Mark Dickinson:
> Eric:  interesting point.  Without having thought about it, I was 
> assuming this was about regenerating configure and pyconfig.h.in in 
> your own working copy (e.g., because you want to test locally some 
> configure script changes) rather than regenerating the configure 
> script in the central repository.

That's roughly what I was doing, yes; sorry for any confusion.

> BTW, should the changes to the generated "configure" be excluded
> from such patches, or should they be included? (to what extent do
> they contain meaningful information during review?)

Not sure.  I think it's fine to leave the configure changes out of a posted patch, especially if you also add a tracker comment reminding potential reviewers to regenerate configure.   If the generated configure changes are small, I don't see a problem with leaving them in the patch either.

> Nitpick: Various occurrences of 2.6.1 in the above should probably be 2.61.
Good catch - I think my brain or fingers are too used to Python's versioning scheme, rather than autoconf's.


Here's a revised set of commands, hopefully fixing that:

$ wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.61.tar.bz2
$ tar -jxf autoconf-2.61.tar.bz2
$ pushd autoconf-2.61
$ ./configure --prefix=$HOME/autoconf-2.61
$ make ; make install
$ popd
$ PATH=~/autoconf-2.61/bin:$PATH autoreconf

> Python's "configure.in" script typically requires a specific version of > autoconf.  At the moment, this reads:
>     version_required(2.61)

This is a bit outdated. Right now we only have:
AC_PREREQ(2.65)

which IIUC means 2.65 or higher.

> Do not edit "configure"; instead, edit "configure.in" and run
> "autoreconf"

"autoreconf" fails for me, but "autoconf" works. I'm not sure what's the difference.

By the way, the dev FAQ is now maintained at http://hg.python.org/devguide/ although this still needs putting in www.python.org.

New changeset 5432be4d4e1a by Ross Lagerwall in branch 'default':
Issue 7997: Explain how to regenerate configure using Autoconf.
http://hg.python.org/devguide/rev/5432be4d4e1a