RFC on plans to implement a c2ffi->cffi generator

[Attila Lendvai]

>> 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.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
There certainly are laws, but human words cannot make one.