Are you all aware of CWrap? It goes a long way to generating pxd files for a C libary. It can, for example, generate valid pxd files for the whole of the Intel IPP library.
This would likely be a good launching point for a GSOC project, unless you really want to start from scratch. https://github.com/enthought/cwrap It's BSD licensed. On Thu, Mar 29, 2012 at 5:10 AM, mark florisson <markflorisso...@gmail.com>wrote: > On 29 March 2012 04:28, Dag Sverre Seljebotn <d.s.seljeb...@astro.uio.no> > wrote: > > On 03/28/2012 07:58 PM, Philip Herron wrote: > >> > >> Hey all > >> > >> I am implemented a very crude and simplistic and very badly programmed > >> version of a pxd generator i think i understand what were after now > >> but i would appreciate if you look over what i did to make sure i have > >> grasped the basic idea for now: > >> > >> So if i have: > >> > >> #include "test.h" > >> > >> int add (int x, int y) > >> { > >> return x + y; > >> } > >> > >> #ifndef __TEST_H__ > >> #define __TEST_H__ > >> > >> extern int add (int, int); > >> > >> struct foobar { > >> int a; > >> unsigned char * b; > >> }; > >> > >> #endif //__TEST_H_ > >> > >> We run gcc -fplugin=./python.so -fplugin-arg-python-script=walk.py > test.c > >> > >> And i output out.pxd: > >> > >> cdef extern from "test.h": > >> int add (int, int) > >> > >> ctypedef struct foobar: > >> int a > >> unsigned char * b > > > > > > Nice. But please use 4 spaces (see PEP 8) :-) > > > > More ideas for project proposal: > > > > Another slight complication is that you should ideally turn > > > > #define FOO 3 > > #define BAR 4 > > > > into > > > > cdef extern from "foo.h": > > enum: > > FOO > > BAR > > > > so you need to hook in before the preprocessor and after the preprocessor > > and dig out different stuff. > > David, I'm CCing you as this might be of interest to you. > > I think the current GCC plugin support doesn't allow you to do much > with te preprocessor, it operates entirely after the C preprocessor > has run. So to support macros we have to consider that for this to > work the gcc plugin may have to be extended, which uses C to extend > GCC and Python, so it also requires knowledge of the CPython C API. > David, would you mind elaborating why C was used for this project and > not (partially) Cython, and would it be possible to extend the plugin > with Cython? > > > Then what happens if you have > > > > #ifdef FOO > > #define BAR 3 > > #else > > #define BAR 4 > > #endif > > > > ?? I'm not saying it is hard, but perhaps no longer completely trivial > :-) > > > > And like Robert hinted at, supporting all the aspects of C++ might take a > > little more work, there's just so much different syntax in C++, and > there's > > several C++ features Cython just does not support and must be either > ignored > > or hacked around (e.g., "const"). > > > > Supporting stuff like > > > > #define MACRO(x) ((x)->field*2) > > > > probably belongs in the category of "must be done manually". > > > > > >> > >> So far in a very crude way it understands structs and functions but > >> nothing else i can see how it could all work but i see now why you see > >> it could be a very small project David's plugin system has mostly > >> everything done for you but i would like to add to his plugin for some > >> tree access code etc... > >> > >> Adding a config file for telling the plugin to not care about certain > >> things would be a nice addition. It seems interesting the clang idea, > >> it could be interesting porting this to other front-ends of gcc like > >> gccgo. > > > > > > Does gccgo use the C ABI so that Cython could call it? If so, go for it! > > > > (Fortran is actually very much in use in the Cython userbase and would > get a > > lot more "customers" than Go, but if you have more of a CS background or > > similar I can see why you wouldn't be so interested in Fortran. I didn't > > believe people were still using Fortran either until I started doing > > astrophysics, and suddenly it seems to be the default tool everybody uses > > for everything.) > > > > Dag > > > > _______________________________________________ > > cython-devel mailing list > > cython-devel@python.org > > http://mail.python.org/mailman/listinfo/cython-devel > _______________________________________________ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel >
_______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
