Feature request: option to treat certain pointers as opaque

[GoogleCodeExporter]

It would be really nice to be able to ask ctypesgen to not recursively define 
certain kinds of pointers and simply treat them as opaque (void *).  For 
example, I keep Berkeley DB "DB *" pointers around.  The python bindings 
shouldn't need to care that it's a DB pointer as I'm never going to dereference 
it, and the fact that it _does_ care means it tries to write wrappers for the 
DB struct, which basically means it tries to write wrappers for all of Berkeley 
DB.  I don't want or need that, and it explodes the size (and complexity) of 
the generated file.

(Thanks for all your work though...great tool!)

Original issue reported on code.google.com by halcyo...@gmail.com on 5 Aug 2011 at 6:27

[mara004]

I believe you can do this with -m / --link-modules. (The pypdfium2-team fork has a fix for relative modules, which makes more accessible a powerful feature that was already woven into the codebase.)

You'll want to create an overrides file such as

# out/overrides.py
import ctypes
DB = ctypes.c_void_p
# ... any other things you might want to override

and use ctypesgen ... -o out/ -m .overrides, so ctypesgen won't create a wrapper for the DB struct, but import and use the symbol(s) provided.

In this light, I believe we don't need an own option for this.

[mara004]

Note that the try/except wrapper around compile-time module importing shown in this branch of ctypesgen is actually harmful, because it would silently capture import errors and return an empty symbols list, which breaks the whole linking logic.

Whoever added this didn't seem to remember that -m is not meant as a mere import, but actually as a strategy to use external symbols (that's also what the help says), which therefore must be known at compile time.

[mara004]

Hmm, now having run into an actual usecase myself, the overrides file turns out to be somewhat clumsy.
Mainly because of relative imports being really temperamental if you don't have an installed package.
The relative modules integration in ctypesgen is also a complicated matter.

I'm not sure yet how to improve this situation.