i imagine it to be similar to how groveling works in iolib, namely: generate the intermediate files from the json files using some ASDF integration, and then compile the lisp files as any other lisp files.
I was thinking it'd be pretty neat to COMPILE-FILE the spec file directly using a custom readtable, but whatever's easier. :-)
that sounds like a nice idea but it may bite us later on because it'd provide less flexibility if we need to cross-reference things in the file and will make debugging also harder, including M-. navigation.
my first question is why isn't this ASDF integration, or something like this, ported into cffi for the gorveler? is there any other reason besides nobody has done it yet?
https://github.com/sionescu/iolib/blob/master/src/grovel/asdf.lisp
Not sure what you mean. This ASDF integration is in cffi-grovel.
sorry, must have been blind and/or confused, i can see it now.
BTW, the scope of the groveller is quite narrow. Things like c2ffi are for grabbing everything a header file has got to offer. The groveller way is just "hey, I know this constant exists, grab me its value please". But, if something like c2ffi turns out to work very well, then we can reimplement the groveller's API on top of it, sure.
there are some issues with the c2ffi approach, too: even though it can extract the #define macro definitions, but its value expressions need to be evaluated somewhere by someone. maybe c2ffi could be extended to invoke the LLVM JIT and eval them?
except that moacro values are not C code, e.g. what about macros that have inputs or do source code string concatenation? at first it sounds reasonable from an FFI perspective to just ignore the ones with inputs, but i have to admit that i didn't think enough about this.
another unresolved issue is inline functions in the header files.
a way to deal with these could be a hybrid approach, namely the generator could group the generated definitions into two or three files with different dependencies:
- one that needs support for call-by-value structs and thus depends on cffi-libffi
- one that needs cffi-grovel? the code could generate a grovel file e.g. to grovel static inline functions from C headers. and if c2ffi cannot evaluate #defines then those, too. the user could add hand-written grovel files also.
- a base set of definitions that only need simple cffi
and users could decide what to depend-on.
Have you seen https://github.com/rpav/c2ffi-cffi?
oh, thanks for reminding me! i've seen it but it slipped out of my mind.
I don't see any showstoppers. cl-autowrap is built on top of CFFI, as is the groveller.
just to be sure: what i'm considering to work on will be a competitor to cl-autowrap.
initially i made quick progress in *using* cl-autowrap, but whenever i try to fix things, or extend it, or get to more complex usage, i get frustrated, and that's why i'm considering this project. plus i'm stuck with something now that needs pass by value.