[issue11487] build_installer.py should avoid relying on a young Python

[David Bolen]

David Bolen <db3l.net at gmail.com> added the comment:

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

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11487>
_______________________________________