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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4