This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: configure.in forces specific autoconf version
Type: compile error Stage: resolved
Components: Build Versions: Python 2.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: alexandre.vassalotti, cavallo71, pitrou, r.david.murray
Priority: normal Keywords:

Created on 2009-07-27 09:39 by cavallo71, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (4)
msg90980 - (view) Author: Antonio Cavallo (cavallo71) Date: 2009-07-27 09:39
Hi,
I've seen the code change in /python/trunk/configure.in (rev.  74072): 
it enforces a specific autoconfig version (2.61) in order to build 
python.

Unfortunately OpenSuSE 11.1 (mainstream at time of writing) has an 
updated version of autoconf 2.63 (and I think is true for Mandriva as 
well). 

Wouldn't be better to force the 2.61 being the minimal version for 
autoconf allowing more up-to-date versions to be used?

You can have a look into http://pyvm.sourceforge.net/ where continuous 
build of the python interpreter are stored for further references.
msg90982 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-07-27 14:00
Does the check trigger when building Python, or only when rebuilding the
configure script itself? I think we ship a prebuilt configure script
precisely so that people don't have to care about autoconf versions and
the like.
msg90984 - (view) Author: Antonio Cavallo (cavallo71) Date: 2009-07-27 15:27
Yes the rebuild does an autoreconf step.
msg90998 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2009-07-27 22:20
My understanding is that the reason that this particular version of
autoconf is required is that newer versions introduce mixed line endings
into the generated file, which causes problems with storing it in svn.

The introduction of the version check was prompted by the fact that
several developers used the wrong autoconf version when regenerating the
configure script because they weren't aware of this issue.  In addition
to this, however, having different developers regenerate the file using
different autoconf versions would result in the checked-in configure
script ping-ponging because of differing autoconf output.  Thus it seems
it is better in the general case to require that the configure script be
built with a specified version of autoconf.
History
Date User Action Args
2022-04-11 14:56:51adminsetgithub: 50834
2009-07-27 22:20:08r.david.murraysetstatus: open -> closed
priority: normal


nosy: + r.david.murray
messages: + msg90998
resolution: not a bug
stage: resolved
2009-07-27 15:27:36cavallo71setmessages: + msg90984
2009-07-27 14:00:53pitrousetnosy: + pitrou
messages: + msg90982
2009-07-27 09:39:18cavallo71create