[fixed up the citation order]

Romain, 07.04.2011 22:36:
2011/4/7 Carl Witty

On Thu, Apr 7, 2011 at 9:06 AM, Dag Sverre Seljebotn wrote:
This seems similar to Carl Witty's port of Cython to .NET/IronPython. An
important insight from that project is that Cython code does NOT specify
an
ABI, only an API which requires a C compiler to make sense. That is; many
wrapped C libraries have plenty of macros, we only require partial
definition of struct, we only require approximate typedef's, and so on.

In the .NET port, the consequence was that rather than the original idea
of
generating C# code (with FFI specifications) was dropped, and one instead
went with C++/CLR (which is a proper C++ compiler that really understands
the C side on an API level, in addition to giving access to the .NET
runtime).

Let me just add that a way to deal with the API vs. ABI issue would be
useful for other potential Cython targets as well, such as IronPython
using C# and Jython.  (A C# port for IronPython would be more valuable
than my C++/CLI port because it would work under Mono -- Mono doesn't
have a C++/CLI compiler and probably never will.)

PyPy has functions to parse C headers to get macros and constants so I could
create C functions to wrap the macros and probably inline constants in the
Python part of the wrapper. This doesn't solve the problem of ifdefs but
this is a start.

Yes, I think this is the only way this can be handled. In the worst case, you'd have to additionally fire up a real C preprocessor and let it parse the referenced header files in order to get at the platform specific declarations, which should then usually be good enough to figure out the ABI.

Stefan
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel

Reply via email to