But I hate, hate, hate, cffi's parsing of include files. Makes my life miserable every time I make a change there.
I'm really hoping DragonFFI takes off.
You can statically link libffi for platforms that don't usually have it installed as a dynamic lib; it adds next to nothing to the footprint.
This could also be a foundation for more than "just" C FFI: it includes a full C++ compiler and JIT! Adding C++ FFI support would take a lot of work I’m sure, but I doubt it would noticeably increase the footprint because the bulk is already in LLVM+Clang. Another possibility would be to JIT Cython-generated code on-demand.
FTR, the footprint of 18Mb is the compressed version, the uncompressed version is ~57Mb. I think there are huge improvements possible here, among them:
* compile llvm with -fvisiblity=hidden
* compile the whole thing with thin lto, which could have the effect to remove unused code
* potentially other idea :)
Did you consider writing a purpose-built JIT compiler? I believe the FFI use-case is narrow enough that a tiny hand-written JIT compiler would be pretty easy... like the old QEMU template based JIT.
(by the way: thank you for libffi!)
One point of my llvm talk of tomorrow is to be able to discuss how we could "extract" these parts from clang to be able to do this the lightest way possible! (but that would still require the embedding of a full LLVM backend which is still huge for the only FFI case).
One good point we have embedding a full compiler is that we can really JIT C code from let's say a python interpreter. The usefulness of this is another debate :)
Said otherwise, I thought the experiment was worth the try, and it seems fun to see how far we can go from here :)
If you only added the signatures and not all the debug stuff the overhead would be pretty small.
Using debug info also make the whole thing potentially usable with other languages that emits functions with the good ABI and DWARF informations.
Some C features are still not supported by dffi (but will be in future releases):
* C structures with bitfields
* functions with triadic arguments
* Example calling three arg function: https://github.com/aguinet/dragonffi/blob/master/examples/ar...
* TODO File: https://github.com/aguinet/dragonffi/blob/master/TODO
So it is about variadic arguments. The reason is time, that is I still didn't take the time to make it work, but it does not seem to have big issues doing it!