I'm seeing this error with 2.6 and 3.1 maint branches (not sure about 2.7) on both Linux & Mac 32-bit builds. Does not happen on Linux 64-bit though. Also this is possibly caused by a recent commit, as we never saw this issue before.

[...]
creating Makefile
./Parser/asdl_c.py -h ./Include ./Parser/Python.asdl
Traceback (most recent call last):
  File "/home/apy/as/pypm-trunk/bin/python", line 49, in <module>
    execfile(__file__)
  File "./Parser/asdl_c.py", line 9, in <module>
    import asdl
ImportError: No module named asdl
make: *** [Include/Python-ast.h] Error 1

I can't reproduce this on 2.6 maint on Linux 32 bit (Gentoo).

Did you try doing a make distclean before redoing the configure/make?

I didn't have to run 'make distclean', because this is a fresh clone.

$ hg clone http://code.python.org/hg/branches/release2.6-maint/
$ cd release2.6-maint
$ ./configure --prefix=`pwd`/i

$ make
./Parser/asdl_c.py -h ./Include ./Parser/Python.asdl
Traceback (most recent call last):
  File "/home/apy/as/pypm-trunk/bin/python", line 49, in <module>
    execfile(__file__)
  File "./Parser/asdl_c.py", line 9, in <module>
    import asdl
ImportError: No module named asdl
make: *** [Include/Python-ast.h] Error 1

Ah, I see what is happening. My $PATH has a buildout's python (bin/python) path. Apparently that is messing up with sys.path. Using /usr/local/bin/python, for instance, in $PATH does not give this problem.

I am not sure how "import asdl" works.

Python is used to build python.  Theoretically you should be able to avoid that rebuild. cf the following thread:

http://mail.python.org/pipermail/python-dev/2006-April/063511.html

and the referenced issue 1465408.  asdl_c.py is going to be importing asdl.py from the same directory it is run from (it is run as a script).  So the question is, why is your buildout python failing to support that import?

> why is your buildout python failing to support that import?

I believe it is because "" (current directory) is not in sys.path for buildout python. Buildout explicitly sets sys.path. Perhaps that's why.

Feel free to close this issue.

That sounds like the likely explanation.