On Dec 4, 2010, at 11:13, "Martin v. Löwis" wrote:

Am 04.12.2010 09:48, schrieb Eli Bendersky:

...

To build the trunk Python 3k, it seems that Python 2 has to be installed. This is because Objects/typeslots.py is called in the Makefile, and this file uses Python 2 "print statement" syntax, which fails if $(PYTHON) is actually Python 3.

This shouldn't be necessary, as typeslots.inc is also checked into subversion, and should have a newer time stamp than typeslots.inc (perhaps not currently, but that is the plan, anyway).

In any case, I now made the script 2-vs-3-agnostic.

Regards, Martin

I had the error pop out in a real build, so the time stamp is probably not a 100% guarantee. Therefore I think it's good that you made it version agnostic. This should be probably be a requirement for all scripts that are part of the build. Thanks, Eli

On Sat, Dec 4, 2010 at 11:41 AM, Antoine Pitrou wrote:

Er, normally you don't need *any* Python installed to build Python (be it 3.x or 2.x).

Are you sure about this? I remember needing an existing Python to building Python 2.7 on a new python-less install of FreeBSD a couple of months ago. But maybe that was just an issue with timestamps on files. I'll see if I can reproduce. Mark

On Sat, Dec 4, 2010 at 1:23 PM, Mark Dickinson wrote:

On Sat, Dec 4, 2010 at 11:41 AM, Antoine Pitrou wrote:

...

Er, normally you don't need *any* Python installed to build Python (be it 3.x or 2.x).

Are you sure about this?  I remember needing an existing Python to building Python 2.7 on a new python-less install of FreeBSD a couple of months ago.  But maybe that was just an issue with timestamps on files.  I'll see if I can reproduce.

With a fresh checkout of the release27-maint branch on an Ubuntu 64-bit VM, with /usr/bin/python renamed to /usr/bin/python_not_here, a './configure && make' fails with: [...] checking for socklen_t... yes checking for build directories... done configure: creating ./config.status config.status: creating Makefile.pre config.status: creating Modules/Setup.config config.status: creating Misc/python.pc config.status: creating Modules/ld_so_aix config.status: creating pyconfig.h creating Modules/Setup creating Modules/Setup.local creating Makefile ./Parser/asdl_c.py -h ./Include ./Parser/Python.asdl /usr/bin/env: python: No such file or directory make: *** [Include/Python-ast.h] Error 127 I think this is the same problem that I saw on the FreeBSD VM. Mark

On Sat, Dec 4, 2010 at 1:40 PM, Benjamin Peterson wrote:

You have to touch Include/Python-ast.h and Python/Python-ast.c. We do this for release tarballs.

Ah, that makes sense. Thanks. Mark

On Sat, Dec 4, 2010 at 15:41, Antoine Pitrou wrote:

Le samedi 04 décembre 2010 à 13:39 +0000, Mark Dickinson a écrit :

...

On Sat, Dec 4, 2010 at 1:23 PM, Mark Dickinson wrote:

...

On Sat, Dec 4, 2010 at 11:41 AM, Antoine Pitrou wrote:

...

Er, normally you don't need *any* Python installed to build Python (be it 3.x or 2.x).

Are you sure about this? I remember needing an existing Python to building Python 2.7 on a new python-less install of FreeBSD a couple of months ago. But maybe that was just an issue with timestamps on files. I'll see if I can reproduce.

With a fresh checkout of the release27-maint branch on an Ubuntu 64-bit VM, with /usr/bin/python renamed to /usr/bin/python_not_here, a './configure && make' fails with:

How about with the release tarball? Perhaps SVN doesn't get timestamps right.

My original problem was that I was re-running 'make' on a svn py3k branch checkout, which already had a compiled ./python exe in its root (Python 3.2, of course). Since the script Objects/typeslots.py (which Martin checked in just yesterday) required Python 2, this failed, although "python" on my machine actually refers to 2.6.5. The failure then happened since in the root of the Python build, "python" referred to the local Python 3 executable. Relying on timestamps sounds a bit too brittle. I think it would be nice if: 1. Parts of the Makefile that use Python checked if Python is installed and generate a useful error if not. 2. All Python scripts that are part of the build should be 2-vs-3 version agnostic for the time being (= until Python 2 is distant history, which won't happen soon) Eli

On Saturday 04 December 2010, Antoine Pitrou wrote:

Perhaps SVN doesn't get timestamps right.

SVN doesn't touch timestamps explicitly, it just writes the files as they come and the system gives them the timestamps. This also makes sense, because the build system depends on them - you don't want the build to skip compiling files after rewinding your working copy to an older version. That said, you can tell SVN to do something with timestamps, I'd have to search a bit in order to find out what exactly that is. Uli ************************************************************************************** Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ************************************************************************************** Visit our website at http://www.dominolaser.com/ ************************************************************************************** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich. **************************************************************************************

Am 06.12.2010 13:18, schrieb Ulrich Eckhardt:

On Saturday 04 December 2010, Antoine Pitrou wrote:

...

Perhaps SVN doesn't get timestamps right.

SVN doesn't touch timestamps explicitly, it just writes the files as they come and the system gives them the timestamps. This also makes sense, because the build system depends on them - you don't want the build to skip compiling files after rewinding your working copy to an older version.

That said, you can tell SVN to do something with timestamps, I'd have to search a bit in order to find out what exactly that is.

What you can ask it to is to use commit times. As you say, this is risky because it may cause build steps to be skipped. What I'm asking for is that the version control gives the files new time stamps, but still imposes a timestamp order, at least on modern file systems (and, as an option, also on old ones). Suppose you do an update spanning 20 revisions. The update should: 1. get the current time T at the beginning of the update 2. fetch all files, and update the contents 3. Touch all files, in the order of the revisions, using microsecond steps (i.e. the oldest file gets T, the next revision T+1µs, the next one T+2µs). As the update probably takes longer than 20µs, all files will have timestamps in the past when the update is done. If the file system does not support subsecond timestamps, you can do the same in second resolution, but that might give you files dated in the future (which make complains about - but you'ld get over with that after 20s). ms might offer some middle ground (but I think all filesystems supporting ms resolution will also support µs). Regards, Martin