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