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.
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
