A shell or Python script should be used to verify that importlib.h actually needs to be rebuilt, and if so make sure that it's even possible (since it depends on a locally built ./python).

The thing should also do a sanity check on the syntax so as to minimize the chances of freezing code that has no chance of working.

What do you mean by "sanity check on the syntax"? The current Makefile rule to build importlib.h already checks the syntax of _bootstrap.py, and fails if there is a syntax error.

On Sun, Apr 22, 2012 at 12:43, Martin v. Löwis <report@bugs.python.org>wrote:

>
> Martin v. Löwis <martin@v.loewis.de> added the comment:
>
> What do you mean by "sanity check on the syntax"? The current Makefile
> rule to build importlib.h already checks the syntax of _bootstrap.py, and
> fails if there is a syntax error

That's true, so ignore my comment. =)

Also, what's the issue with a shell script? The current Makefile will rebuild importlib.h if its time stamp is older than the one of _bootstrap.py. That will fail if ./python was not build.

So what is the problem to solve?

I don't quite follow. I have no issue with a shell script verifying things  by doing an `hg status` to verify certain truths (or something). I said a shell *or* Python script to begin with.

My point is: ISTM that everything is already as it should be, I can see no problem in the status quo. If there is a problem, can you please rephrase it? If you want a shell script just to have one, here is one

#!/bin/sh
make Python/importlib.h

No, I don't want a shell script just to have one. =)

The status quo seems to work, but people like Georg think it's partially luck that it does and if hg changes its semantics that will cause us trouble.

New changeset acfdf46b8de1 by Marc-Andre Lemburg in branch 'default':
Issue #14605 and #14642:
http://hg.python.org/cpython/rev/acfdf46b8de1

This is where a script could help with printing out a warning if the built Python interpreter is not available.

> The status quo seems to work, but people like Georg think it's partially luck that
> it does and if hg changes its semantics that will cause us trouble.

Could you expand on that?

When you do a fresh checkout, Python/importlib.h comes after Lib/importlib/_bootstrap.py and Python/freeze_importlib.py in a lexicographical sort which leads to it have a newer timestamp and thus not triggering a new build of the file.

This is why Martin suggested at some point using hg status or something from a script to properly detect if something has changed that would warrant rebuilding.

New changeset 5fea362b92fc by Marc-Andre Lemburg in branch 'default':
Issue #14605 and #14642: Issue a warning in case Python\importlib.h needs to
http://hg.python.org/cpython/rev/5fea362b92fc

I'm working on a "hg touch" extension which is able to bring the time stamps back in correct order after a checkout. One would either do "make touch" after an update, or register that extension as a post-update action in .hg/hgrc. It will be controlled by a versioned .hgtouch file, that uses make(1) dependency syntax.

New changeset b3d3f3238c13 by Martin v. Loewis in branch 'default':
Issue #14642: Add "hg touch" extension, and "make touch" target.
http://hg.python.org/cpython/rev/b3d3f3238c13

Can this issue be closed, Martin, thanks to your extension?

As I don't fully understand what the original issue was, I can't know for sure whether it's fixed now. But yes, there is now a mechanism to bring the time stamps in the right order.