Simon Burton wrote:
>>>> I would like to expose some functions as external
>>>> symbols when i build a .so
>>>>
>>>> def foo(i, j):
>>>> return i+j
>>>>
>>>> foo._expose_ = [rffi.INT, rffi.INT]
>>>>
> well, the above code would produce:
>
> extern int foo(int i, int j)
> {
> return i+j;
> }
>
> (and perhaps an accompanying .h file)
>
> thereby providing an interface for other C programs.
> This is rffi producing rather than consuming a C interface.
I think that what you need is similar to what carbonpython does:
basically, carbonpython is a frontend for the translation toolchain that
takes all the exposed functions/classes in an input file and produce a
.NET libraries to be reused by other programs.
Functions are exposed with the @export decorator:
@export(int, int)
def foo(a, b):
return a+b
The frontend creates a TranslationDriver objects, but instead of calling
driver.setup() it calls driver.setup_library(), which allows to pass
more than one entry point. I think all this could be reused for your needs.
Then, the next step is to teach the backend how to deal with libraries;
for genc, this would probably mean not to mangle functions names, to
create a companying .h and to modify the Makefile to produce a .so
instead of an executable.
About name mangling: one possible solution could be to mangle the names
as now and put some #define in the .h to allow the programmer to use
non-mangled names. Probably this is the less invasive solution.
ciao Anto
_______________________________________________
[email protected]
http://codespeak.net/mailman/listinfo/pypy-dev
