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

[Ned Deily]

Ned Deily added the comment:

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.

--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Santoso Wijaya]

Changes by Santoso Wijaya :


--
nosy: +santa4nt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ronald Oussoren]

Ronald Oussoren  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ned Deily]

Ned Deily  added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[David Bolen]

David Bolen  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> 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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[David Bolen]

David Bolen  added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[David Bolen]

David Bolen  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ronald Oussoren]

Ronald Oussoren  added the comment:

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).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[David Bolen]

David Bolen  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ronald Oussoren]

Ronald Oussoren  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ronald Oussoren]

Ronald Oussoren  added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

New submission from Antoine Pitrou :

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.

--
assignee: ronaldoussoren
components: Build, Macintosh
keywords: buildbot
messages: 130766
nosy: db3l, ned.deily, pitrou, ronaldoussoren
priority: low
severity: normal
status: open
title: build_installer.py should avoid relying on a young Python
type: compile error
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com