Re: ffi.cdef() for module writers
- From: Peter Colberg <peter@xxxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Fri, 12 Oct 2012 20:10:33 -0400
Hi Brian,
On Fri, Oct 12, 2012 at 03:44:26PM -0700, Brian Maher wrote:
> Unfortunately, this method gets rather tedious... today I simply run
> `gcc -E cdef.h` to generate the c definitions for my lua modules (and
> perhaps grep out the bits I care about). So, it seems that I should
> write a tool to parse the C header files and generate the various
> cdef/*.lua modules... but I don't see a straight forward way of doing
> this without writing a C parser.
I am actually working on (avoiding) the C parser bit at the moment.
The problem I would like to solve is to generate portable, forward
compatible FFI bindings for a variety of interfaces, e.g., POSIX,
MPI, HDF5. Implementations make significant use of preprocessor
mangling, and grepping out the bits and pieces using Lua pattern
matching is tedious and fragile.
LuaJIT has a very good C parser, which can be queried using Peter
Cawley's reflection library [1]. This approach, however, does not
work when generating FFI bindings for a non-native target platform,
and depends on LuaJIT internal data structures.
[1] http://article.gmane.org/gmane.comp.lang.lua.luajit/87
GCC supports dumping an AST (-fdump-translation-unit) into a text
file, which can be easily parsed using a Lua script. This approach
supports cross-compilation, and works on Unix and Windows platforms
(using mingw32-gcc). The output is documented in gcc/tree-dump.c,
and intended as an internal developer tool.
This allows querying typedefs (the "uncl" attribute is especially
helpful), function declarations, and variable declarations. The latter
can be used to extract constants and symbol names, in case a symbol
name does not match its API name due to preprocessor mangling.
Peter
Other related posts:
