belred1 at yahoo.com
Tue Aug 5 02:16:12 CEST 2003
"John Machin" <sjmachin at lexicon.net> wrote in message news:c76ff6fc.0308041422.3d819d78 at posting.google.com...
> "Bryan" <belred1 at yahoo.com> wrote in message news:<7NtXa.62774$uu5.6090 at sccrnsc04>...
> > "Gerhard Häring" <gh at ghaering.de> wrote in message news:mailman.1059853685.20382.python-list at python.org...
> > > Bryan wrote:
> > > > [PyRex produces code using staticforward that won't work in the combination Python 2.3/MSVC]
> > > In the PySQLite sources, I added this snippet on top:
> > >
> > > #ifdef _MSC_VER
> > > #define staticforward extern
> > > #endif
> > >
> > > to make it compilable under MSVC/Python 2.3. *After* #include-ing
> > > "Pyhton.h" of course.
> > i've decided to go with gerhard's approach with one minor modification:
> > #ifdef _MSC_VER
> > #undef staticforward
> > #define staticforward extern
> > #endif
> > this solution is best for me because i want to take the resulting c file and give it to others so they can compile it on other
> > and compilers.
> > why can't this code be placed in the pyrex header? seems like a simple fix.
> What gave you the impression that it can't be put in? You tell us why
> *you* can't put it in.
because i don't have the experience to do so. the fact you think the above #ifdef is a kludge proves it and i'm not even the one
who came up with those 4 lines.
> I'll tell you why it *shouldn't* be put in: because it's a kludge. The
> offending C code is a forward declaration of a char  which is
> subsequently filled in with the name of the source .pyx file which is
> known at the time the staticforward is emitted. The principled fix is
> to declare and define the array in one hit.
More information about the Python-list