classification
Title: http://www.python.org/dev/faq/ doesn't seem to explain how to regenerate "configure"
Type: enhancement Stage: resolved
Components: Documentation Versions:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: rosslagerwall Nosy List: brett.cannon, dmalcolm, eric.smith, georg.brandl, mark.dickinson, pitrou, python-dev, rosslagerwall
Priority: normal Keywords:

Created on 2010-02-22 23:53 by dmalcolm, last changed 2012-03-18 13:59 by rosslagerwall. This issue is now closed.

Messages (9)
msg99882 - (view) Author: Dave Malcolm (dmalcolm) (Python committer) Date: 2010-02-22 23:53
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
msg99884 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-02-23 00:24
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.
msg99886 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2010-02-23 00:31
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?
msg99891 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-02-23 01:02
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.
msg99895 - (view) Author: Dave Malcolm (dmalcolm) (Python committer) Date: 2010-02-23 03:43
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.
msg99904 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-02-23 09:18
> 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.
msg100950 - (view) Author: Dave Malcolm (dmalcolm) (Python committer) Date: 2010-03-12 18:26
> 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
msg128354 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-02-11 00:15
> 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.
msg155397 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2012-03-11 17:24
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
History
Date User Action Args
2012-03-18 13:59:02rosslagerwallsetstatus: open -> closed

type: enhancement
assignee: rosslagerwall
nosy: + rosslagerwall
resolution: fixed
stage: resolved
2012-03-11 17:24:10python-devsetnosy: + python-dev
messages: + msg155397
2011-02-11 00:15:35pitrousetnosy: + pitrou
messages: + msg128354
2011-02-10 23:34:39brett.cannonsetassignee: brett.cannon -> (no value)
nosy: brett.cannon, georg.brandl, mark.dickinson, eric.smith, dmalcolm
2010-04-23 18:37:34brett.cannonsetpriority: normal
2010-03-12 19:58:44brett.cannonsetassignee: georg.brandl -> brett.cannon
2010-03-12 18:26:25dmalcolmsetmessages: + msg100950
2010-02-23 21:47:03georg.brandlsetnosy: + brett.cannon
2010-02-23 09:18:41mark.dickinsonsetmessages: + msg99904
2010-02-23 03:43:36dmalcolmsetmessages: + msg99895
2010-02-23 01:02:04mark.dickinsonsetmessages: + msg99891
2010-02-23 00:31:01eric.smithsetnosy: + eric.smith
messages: + msg99886
2010-02-23 00:24:36mark.dickinsonsetnosy: + mark.dickinson
messages: + msg99884
2010-02-22 23:53:59dmalcolmcreate