[Python-Dev] serious bug in new import X as Y code (original) (raw)

Sjoerd Mullender sjoerd@oratrix.nl
Sun, 20 Aug 2000 11:22:28 +0200

Why don't we handle graminit.c/graminit.h the same way as we currently handle configure/config.h.in? The person making a change to configure.in is responsible for running autoconf and checking in the result. Similarly, the person making a change to Grammar should regenerate graminit.c/graminit.h and check in the result. In fact, that is exactly what happened in this particular case. I'd say there isn't really a reason to create graminit.c/graminit.h automatically whenever you do a build of Python. Even worse, when you have a read-only copy of the source and you build in a different directory (and that used to be supported) the current setup will break since it tries to overwrite Python/graminit.c and Include/graminit.h.

I'd say, go back to the old situation, possibly with a simple Makefile rule added so that you can build graminit, but one that is not used automatically.

On Fri, Aug 18 2000 "Fredrik Lundh" wrote:

sjoerd wrote:

> The problem was that because of your (I think it was you :-) earlier > change to have a Makefile in Grammar, I had an old graminit.c lying > around in my build directory. I don't build in the source directory > and the changes for a Makefile in Grammar resulted in a file > graminit.c in the wrong place. is the Windows build system updated to generate new graminit files if the Grammar are updated? or is python development a unix-only thingie these days?

-- Sjoerd Mullender <sjoerd.mullender@oratrix.com>