dunk wrote:
hi,something i have been wondering for a long time: if i want to create, for example, a class that derives from CoordSyst and i want to use pyrex for speed when running my own open gl calls. the module wants to be seperate from soya as id want it game specific. i read about the pyrex declarations but im still a bit confused :) i can, for example again, create a file called test.pyx and put in it: cimport _soya.pxd cdef class MyTest(_soya.CoordSyst): pass then i run $ pyrex -I /path/to/my/soya test.pyx at this point everything seems fine the resulting test.c file however seems to contain a lot of soya stuff. gcc -c -fPIC -I/usr/include/python2.3 test.c is about as far as ive got with compiling! i kind of imagine it as a seperate module linked to soya.so but things get a bit fuzzy in my brain around here :)
Use distutils to compile Pyrex extensions. Use Soya's setup.py as an example. Also, it should be cimport _soya, without the .pxd at the end. The .c file will contain the C code for all the declarations that are in the .pxd file. Where else would you expect the module to get its hands on them? It can't magically extract them from _soya.so at runtime. This includes all the class definitions, but not the actual method code. Think of it as including the .h file in your code instead of including it separately. One of these days I want to write a compiler for real Python code, but that's probably a ways off, as I know absolutely nothing about type snarfing. It'd be based on compiler.py.
signature.asc
Description: OpenPGP digital signature
