Hi All, I have created a helper for generating FFI code for Guile. The current use case is to create file called a "ffi module" that specifies includes and libraries that will be used to create a loadable Guile module. In the process, the FFI Helper (FH) parses C code and, from that, generates Guile FFI code. See
ffi-helper: https://www.nongnu.org/nyacc/ffi-help.html project: https://savannah.nongnu.org/projects/nyacc I think the package is at a very usable point right now, and I am starting to converge on a 1.0 release. So now I am soliciting inputs on other ways to use this package. Namely, are convenience routines needed for some use cases? For example, one user wanted to be able to write `(include "cairo.h")'. As you may imagine, it can't be this simple. I do have this: guile> (load-include-file "cairo.h" #:pkg-config "cairo") but even this is a bit of a challenge for me. Not to write the code, but to digest the whole use case. Do you want the generated scheme code preserved? If so, do I need to provide an option for setting the output file name? If a "pkg-config" is not available then the user will need to pass compile flags (e.g., include dirs), load flags, libraries, etc. I would need to add more options for this. It could get messy. All that functionality lives in the "ffi-module" paradigm right now, so maybe this is really not needed. What do you think? Maybe you are generating FFI yourself but want to see what FH would do for a specific struct typedef appearing in a particular include file. You can do this with the ffi-module approach, using the #:decl-filter option which allows one to restrict which declarations get expanded. Is a separate convenience routine needed? Currently I think all other uses can be derived from the current "ffi module" paradigm. Making convenience routines is going to be tricky, because so many options may need to added. I don't think it's worth the work to add them, but I'd like to hear what you have to say. Comments? Matt
