[Python-Dev] serious bug in new import X as Y code

[Sjoerd Mullender]

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?
> 
> </F>
> 
> 

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