homepage

Here's the "make -d" output:
 Prerequisite `Parser/Python.asdl' is older than target
`Include/Python-ast.h'.
 Prerequisite `Parser/asdl.py' is older than target
`Include/Python-ast.h'.
 Prerequisite `Parser/asdl_c.py' is newer than target
`Include/Python-ast.h'.
 Must remake target `Include/Python-ast.h'.
./Parser/asdl_c.py -h ./Include ./Parser/Python.asdl
/usr/bin/env: No such file or directory
And these are the file times:
orig/Python-2.6b2> ls -l Include/Python-ast.h
-rw-r--r-- 1 lemburg users 20081 2008年03月30日 08:40 Include/Python-ast.h
orig/Python-2.6b2> ls -l Parser/asdl*
-rw-r--r-- 1 lemburg users 11306 2006年03月01日 23:49 Parser/asdl.py
-rwxr-xr-x 1 lemburg users 39771 2008年06月09日 06:58 Parser/asdl_c.py
Because Python-ast.h is older than the script used for generating it
(asdl_c.py), it always tries to rebuild the .h file. Since this requires
Python to be installed, it fails on a machine that doesn't always have
an existing Python binary installed.
This happens in both 2.6b1 and 2.6b2.
I guess the release process should make sure that the Python-ast.h and
Python-ast.c are always newer than the scripts used to build them.

As work-around, you can untar the source tarball and then touch the
files in question:
touch Include/Python-ast.h
touch Python/Python-ast.c 

It should be simple to modify release.py to touch these files. Barry,
I'm on vacation now, but I should be able to do this before you spin the
releases.

This happened in my fresh unpack of the 3.0b2 tarball, as well.
Touching merely Include/Python-ast.h satisfied the dependency, and I did
not have to touch Python-ast.c. Is the particular grammar-rebuild rule
needed for production tarballs anyway? I can't think the majority of
people downloading the package want to start hacking the grammar right away.

Ok. I've updated release.py to do the dirty work in 65708.