Skip to main content
gamedev.net
🔒 Locked

My python 2.5 distutils nightmare

Started by smr Jan 6, 2007 at 8:54 PM 7 replies 1.3k views
Original Post
smr
smr
I have been trying to build a python extension built with pyrex for the last few hours. The problem is this:
Quote:
F:\Projects\Battle\renderer>python setup.py build_ext running build_ext building 'test' extension error: Python was built with version 7.1 of Visual Studio, and extensions need t o be built with the same version of the compiler, but it isn't installed.
Okay. This should be a simple problem to resolve. I'll just go download and install the free VC++ 2003 toolkit from Microsoft. I go to the download page, and I'm greeted by this friendly message:
Quote:
http://msdn2.microsoft.com/en-us/visualc/aa336490.aspx The Visual C++ Toolkit 2003 has been replaced by Visual C++ 2005 Express Edition...
I cannot find the 2003 toolkit anywhere. I understand that it's probably illegal for anyone but MS to distribute, but damn, this is a real pain in the ass. At this point the only solution I can come up with is to compile python myself with VC++ 8 and hope that any extension modules I've downloaded will work with it, since they probably link against msvcrt71. Does anyone know how to compile a python extension for windows without VC++ 7.1?
smr
smr
Nevermind. I've decided to write my library in C++, then access it from python with ctypes. Thanks to anyone who might have tried to find a solution.
Kylotan
Kylotan
If you search the comp.lang.python newsgroup (via Google Groups, if you like), you'll see this comes up a lot. There's a web page somewhere that tells you how to set up Mingw32 to compile Python extensions.
Tenjou_Utena
Tenjou_Utena
Note that ctypes doesn't do C++ classes as far as I know.

I ended up going with boost.python. But, I also ended up recompiling python and pygame using VS8.0, so...
smr
smr
Quote:
Original post by Tenjou_Utena
Note that ctypes doesn't do C++ classes as far as I know.

I ended up going with boost.python. But, I also ended up recompiling python and pygame using VS8.0, so...


Yeah I've worked around it. Essentially I've written a C interface for any classes that I need to export. I'm really sticking to the idea of not writing anything in C++ unless its absolutely necessary, so really there isn't much data being shared between python and my C/C++ methods. I've read that ctypes has an automatic wrapper generator. Maybe it'll suit my purpose. If not it'd be relatively trivial to write one that would work just for my project.

In case anyone's curious, essentially here's how I'm doing it. I'm open to suggestions:

C++ code
class MyClass{public:    MyClass();    ~MyClass();    int Method(int v);}// C interface functionstypedef void* CTYPES_HANDLE;#define CTYPES_CALL __cdeclCTYPES_HANDLE CTYPES_CALL MyClass_new(){    return new MyClass();}void CTYPES_CALL MyClass_delete(MyClass* p){    delete p;}int CTYPES_CALL MyClass_Method(MyClass* p, int v){    p->v;}

class MyClass:    def __init__(self):        # needed so GC doesn't destroy it until this class is destroyed        self._ctypes_dll = _ctypes_dll         self._native = self._ctypes_dll.MyClass_new()        def __del__(self):        self._ctypes_dll.MyClass_delete(self._native)    def MyMethod(self, v):        self._ctypes_dll.MyClass_MyMethod(self._native, v)


It's working well so far. It's also easy to leverage the python garbage collector to manage these native objects, making sure that the __del__ method calls the native delete.

[Edited by - smr on January 8, 2007 1:49:16 PM]
doctorsixstring
doctorsixstring
Quote:
Original post by Kylotan
There's a web page somewhere that tells you how to set up Mingw32 to compile Python extensions.


Are you referring to this? I believe that is what I used to setup Pyrex on my laptop a few months ago. Of course, like most things, I promptly forgot how to do it immediately after finishing. I don't remember it taking more than a few hours, and I don't need to have any large MS libraries installed for it, so I would highly recommend it.
Kylotan
Kylotan
That does appear to be close to the steps I've read elsewhere, yes. It's a shame that Python is set up in such a proprietary way in the first place, and also that there's no standard interface that would work regardless of compiler, but there's little we can do about that.
smr
smr
I think the reason why they restrict you to using the same version is to prevent modules from linking against a different version of libc/msvcrt than the interpreter. Doing so could create all kinds of problems with file handles being shared between the module and python. Maybe even memory too, because there's no guarantee that you an reliably call free() on memory allocated with a different version of libc/msvcrt.
Kylotan
Kylotan
Yes, but what I'm saying is that you can create interfaces that don't require that sort of link-time dependency. Most DLLs you use don't require different versions for different compilers.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.