Hi again<div><br></div><div>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&#39;t solve the problem of ifdefs but this is a start.</div>
<div><br></div><div>Cheers</div><div>Romain<br><br><div class="gmail_quote">2011/4/7 Carl Witty <span dir="ltr">&lt;<a href="mailto:carl.witty@gmail.com">carl.witty@gmail.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, Apr 7, 2011 at 9:06 AM, Dag Sverre Seljebotn<br>
&lt;<a href="mailto:d.s.seljebotn@astro.uio.no">d.s.seljebotn@astro.uio.no</a>&gt; wrote:<br>
</div><div class="im">&gt; This seems similar to Carl Witty&#39;s port of Cython to .NET/IronPython. An<br>
&gt; important insight from that project is that Cython code does NOT specify an<br>
&gt; ABI, only an API which requires a C compiler to make sense. That is; many<br>
&gt; wrapped C libraries have plenty of macros, we only require partial<br>
&gt; definition of struct, we only require approximate typedef&#39;s, and so on.<br>
&gt;<br>
&gt; In the .NET port, the consequence was that rather than the original idea of<br>
&gt; generating C# code (with FFI specifications) was dropped, and one instead<br>
&gt; went with C++/CLR (which is a proper C++ compiler that really understands<br>
&gt; the C side on an API level, in addition to giving access to the .NET<br>
&gt; runtime).<br>
<br>
</div>Let me just add that a way to deal with the API vs. ABI issue would be<br>
useful for other potential Cython targets as well, such as IronPython<br>
using C# and Jython.  (A C# port for IronPython would be more valuable<br>
than my C++/CLI port because it would work under Mono -- Mono doesn&#39;t<br>
have a C++/CLI compiler and probably never will.)<br>
<font color="#888888"><br>
Carl<br>
</font></blockquote></div><br></div>