(original) (raw)
On Tue, Aug 30, 2011 at 10:05 AM, Guido van Rossum <guido@python.org> wrote:
It's certainly a harder problem.
For most simple constants, Cython/Pyrex might be able to generate a series of tiny C programs with which to find CPP symbol values:
#include "file1.h"
...
#include "filen.h"
main()
{
printf("%d", POSSIBLE_CPP_SYMBOL1);
}
...and again with %f, %s, etc.� The typing is quite a mess, and code fragments would probably be impractical.� But since the C Preprocessor is supposedly turing complete, maybe there's a pleasant surprise waiting there.
But hopefully clang has something that'd make this easier.
SIP's approach of using something close to, but not identical to, the .h's sounds like it might be pretty productive - especially if the derivative of the .h's could be automatically derived using a python script, with minor tweaks to the inputs on .h upgrades.� But sip itself is apparently C++-only.
On Tue, Aug 30, 2011 at 9:49 AM, "Martin v. L�wis" <martin@v.loewis.de> wrote:
The problem lies with the PyPy backend -- there it generates ctypes
code, which means that the signature you declare to Cython/Pyrex must
match the *linker* level API, not the C compiler level API. Thus, if
in a system header a certain function is really a macro that invokes
another function with a permuted or augmented argument list, you'd
have to know what that macro does. I also don't see how this would
work for #defined constants: where does Cython/Pyrex get their value?
ctypes doesn't have their values.
So, for PyPy, a solution based on Cython/Pyrex has many of the same
downsides as one based on ctypes where it comes to complying with an
API defined by a .h file.
It's certainly a harder problem.
For most simple constants, Cython/Pyrex might be able to generate a series of tiny C programs with which to find CPP symbol values:
#include "file1.h"
...
#include "filen.h"
main()
{
printf("%d", POSSIBLE_CPP_SYMBOL1);
}
...and again with %f, %s, etc.� The typing is quite a mess, and code fragments would probably be impractical.� But since the C Preprocessor is supposedly turing complete, maybe there's a pleasant surprise waiting there.
But hopefully clang has something that'd make this easier.
SIP's approach of using something close to, but not identical to, the .h's sounds like it might be pretty productive - especially if the derivative of the .h's could be automatically derived using a python script, with minor tweaks to the inputs on .h upgrades.� But sip itself is apparently C++-only.