There was this failure in the daily DMG builder:
http://www.python.org/dev/buildbot/all/builders/3.x.dmg/builds/423/steps/compile/logs/stdio

The problem is that asdl_c.py gets run by the Makefile with the standard Python, which on this machine is 2.3.5 (according to David).
The easy solution would be to freshen the timestamps of Include/Python-ast.* in build_installer.py.

I noticed this myself as well when building a fresh checkout, without build_installer.py. 

This is because the header file and input grammar have the same timestamp, and which forces the rebuild.

That causes problems on OSX when you build with a different deployment target than the one used to build the python command on $PATH. 

I'm not familiar enough with mercurial to know if there is a way to ensure that the header file has a new timestamp when checking in an updated grammer (IIRC you could do this with SVN by first checking in the grammar file and then the generated files).

I'm +O on updating build_framework.py, it should be safe enough as developers should be carefull enough when updating the grammar file.

To avoid duplicate work: I'll commit a patch during the pycon sprints

Just a few thoughts that were in part in an earlier exchange with Antoine.

It seems to me that if the Python-ast.[ch] files are included in the repository then they ought to be up to date as part of any given change set.  So I think I'd actually prefer having them touched in the master copy to avoid needing to be rebuilt (e.g., what presumably has been true up until this most recent change, although I'm not sure if switching to hg has changed something in this area).

If that isn't feasible (but the files are still in the repository) then there probably does need to be some way for the build-installer process to permit a more-recent-than-system python to be used.  However, it goes to some lengths (understandably) to avoid the risk of corruption from local system files, so it's not clear how to generically make a build script that uses "/usr/bin/env python" to work.

Manually touching the output files, either by build-installer, or a separate step in the build process controlled by the master (like the current umask step) seems to be least attractive, since there's no way to know for sure that the files are really up to date that way, right?  If they are up to date, then a checkout ought to reflect that, no?

-- David

This does not only affect the installer.

On my machine the python on $PATH was build using the 10.6 deployment target. When I build python from a fresh checkout I get an error message because the 10.6 python gets run with deployment target 10.4 and then barfs (which in itself is a problem that needs to be fixed).

Note that some of my last comment was before I saw the others, so I'm fine with script changes if that seems ok to others.

From Ronald:

"This is because the header file and input grammar have the same timestamp, and which forces the rebuild."

Note in the buildbot case the .[ch] files have much older timestamps than the generator script.  I think if they were the same it would be ok.  

I suspect this may be an issue now because the old svn approach was a full checkout for each build, whereas the hg approach is to pull to the local clone, and then just update the build tree.  So in the svn case all the files would have a good shot at the same timestamp, whereas with the hg approach the generated files get stale if the contents don't change.

I wonder if just doing a full checkout from the local clone would be closer to the old svn behavior in general with respect to timestamps and maybe a reasonable policy?

-- David

Note in the meantime, I've manually touched those two files on the dmg buildbot and it builds successfully.  As Antoine pointed out to me separately, the hg update used by the buildbot should leave that intact, so this should stop any buildbot failures for the time being, or until the source dependencies are touched again.

> I suspect this may be an issue now because the old svn approach was a
> full checkout for each build, whereas the hg approach is to pull to
> the local clone, and then just update the build tree.  So in the svn
> case all the files would have a good shot at the same timestamp,
> whereas with the hg approach the generated files get stale if the
> contents don't change.
> 
> I wonder if just doing a full checkout from the local clone would be
> closer to the old svn behavior in general with respect to timestamps
> and maybe a reasonable policy?

Ok, I've made the change on the DMG builders.

(the change will probably make things worse actually; see http://bugs.python.org/issue11419)

Guess I cry uncle - not sure how it used to work then.  I just did a dummy svn checkout off of the older svn.python.org from trunk and the .[ch] files appear to have dates earlier than the asdl.py script, so I would have assumed it would have the same problem.  Yet I don't recall this being an issue on the DMG slave, so guess we were just lucky somehow.

-- David

Note, there is a fix for the "$MACOSX_DEPLOYMENT_TARGET mismatch" Ronald mentions in Issue9516 and is only a problem if, during the build, /usr/bin/env python is a Python 2.7 that was built with a different deployment target.  Python 2.6 and earlier are not susceptible to this problem.  (3.2 is also susceptible but is unlikely to be the target of /usr/bin/env python).  Of course, fixing future releases of Python2.7 does not help current builds.

Issue11485 contains a comment of someone that ran into the same issue is me.

The changes for Issue21383 added calls to "make touch" to build_installer.py so the initial problem reported here should no longer occur on any OS X installer build.  As to the more general problem of needing to use "make touch" because hg checkouts do not preserve original file checkin time orders, there have been multiple issues opened (and closed) on that subject; there's no need to keep this issue open for that.