This happens when I run configure for python 2.7.2 on FreeBSD
...
cc -c -fno-strict-aliasing -O2 -fno-strict-aliasing -pipe -march=nocona  -DNDEBUG -O2 -fno-strict-aliasing -pipe -march=nocona  -I. -IInclude -I./../Include -fPIC -DPy_BUILD_CORE -o Python/Python-ast.o Python/Python-ast.c
cc: Python/Python-ast.c: No such file or directory
cc: No input files specified
*** [Python/Python-ast.o] Error code 1

Stop in /usr/ports/lang/python27/work/Python-2.7.4/portbld.shared.

if the Python/Python-ast.c file does not exist in the Python source directory, try re-extracting it (if the file still doesn't exist then you probably have a corrupt compressed file)

Python-ast.c is a generated file.  As released, a Python source tarball should contain an up-to-date version that does not need to be regenerated. However, if the timestamps of the source files are not preserved, the Makefile may think it is out of date and try to regenerate it. The regeneration step requires a working Python compiler so you may run into a bootstrap issue if there is none on the system.  If you obtain the source using a Mercurial checkout, hg does not attempt to set timestamps on the source files so you are even more likely to run into problems in that case.  Usually, the solution is to do a clean checkout or tarball extraction, then manually "touch" the files that Python-ast.c is built from:

    touch Include/Python-ast.h Python/Python-ast.c

The newly-released Python 2.7.4 includes a "make touch" target in the Python Makefile just for this purpose, see Issue16004 and a number of other changes to help make this area more robust, for example, when building with a BUILDIR separate from SRCDIR.

I looked and the file exists:
$ file Python/Python-ast.c
Python/Python-ast.c: C source, ASCII text

The file appears valid.

I touched the files as suggested but I still I get the same error message when running "configure".

FWIW, the Makefile.pre.in target exists but it doesn't seem useful because this happens just by running configure (when there is no Makefile).
I should note that I am attempting to build within FreeBSD's ports tree (apparently out-of-tree) so maybe my environment setup is causing the trouble.

Correction:
The problem does arise during the build process (not configure).

Still specifying the touch target for the build or touching manually the files doesn't help :(

I'm afraid it's not likely we'll be able to further resolve this issue without more specific information about exactly the steps you are using to try to build Python, including exactly what version or hg rev id (you say 2.7.2 but the path name says 2.7.4), any patches, exact ./configure parameters, which version of FreeBSD, etc.  I can tell you that python-dev has a set of buildbots including some FreeBSD ones that seem to be able to build successfully, for example http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.1%20%5BSB%5D%202.7.  I'm not sure how that compares to what you are trying to do by building "within FreeBSD's ports tree".

Oops.. I am sorry I reported the wrong version,
I am using python-2.7.4 just released

SHA256 (python/Python-2.7.4.tar.xz) = b6626eb6d07d72351f251116ab14427fc934b5f24e6ebc751356a44a7d23b62d
SIZE (python/Python-2.7.4.tar.xz) = 10250644

And I am running something similar to your buildbot:
FreeBSD pcbsd-3938 9.1-STABLE FreeBSD 9.1-STABLE #9 r248799M: Wed Mar 27 15:23:28 COT 2013     pfg@pcbsd-3938:/sys/amd64/compile/DELL  amd64

I am afraid the issue is caused by the ports tree environment: it does some nasty workarounds to avoid building some components.

Let's just close this issue, I will investigate locally and if I find something wrong in the release I will let you know, Thanks for your help!

The problem is Makefile.pre.in was changed in a way that stops out-of-tree builds.

The following patch by Markus Von Appen fixes it.

Ruslan Makhmatkhanov provided this (more complete) patch.

I believe there are two different issues here. One: since the python-dev switch to hg, Python source release tarballs no longer have had consistent file time stamps which result in unnecessary generation steps being run in a build. Python 2.7 and 3.3 now include the "make touch" target to manually fix the timestamps for generated files and, in Issue18008, changes were made to the release process scripts so that future source tarballs will be produced with consistent timestamps and these spurious generation steps should no longer run.  The second issue is making sure that, if you are building from a repo or possibly with separate, out-of-tree build directory, generated files are built correctly and are used as expected in the build.  There are a number of subtle points involved in getting this right for all cases; Issue15819 has been tracking these points.  I'm going to close this issue as a duplicate of it and suggest any further discussion take place there.