Hi Danny, Danny Milosavljevic <dan...@scratchpost.org> skribis:
>> Matt Wette, the author of nyacc, was apparently in the process of >> writing a similar tool using nyacc’s C99 parser. Might be worth >> looking at. > > Nice! I've actually thought about using nyacc and mes for that - but > since we use gcc to compile everything, we can also use gcc to find > out what it compiled Sure; I think Matt’s idea is just to use nyacc’s cpp/C99 parser to extract function declarations, nothing more. >> Besides and FWIW, I’m skeptical of binding generators. Things like >> SWIG, for instance, generate interfaces that are often not quite >> what you’d like, so you end up writing a layer on top of the >> generated glue anyway, not to mention annotation in headers. > > Yeah, probably the bindings will suck a bit. But one can always write > a wrapper and not export all the original functions from there. Rust > for example has a "...-sys" convention where the package "foo-sys" > contains the easily-generated bindings and the package "foo" contains > the actually simple high-level bindings. > > What I don't want is to manually maintain all the bindings. It's a > computer, it should automate it :P > > Writing "override" declarations (or maybe even just literally > overwriting the definition in Scheme) once every few months I'm fine > with. Adapting the bindings every time upstream adds a function? No. > > If I plan to use something like the "...-sys" convention in Guile, can > I somehow re-export all the same names as the "-sys" package did, in a > non-sys package? > > For example: > > (define-module (foo-sys) #:export (a b c)) Yes, that’s a workable plan. I’m unsure this approach saves a lot of time over “hand-written” FFI bindings (I write “hand-written” with quotes because usually you’d come up with macros to do the heavy lifting for the library you’re wrapping), but maybe you’re right! Ludo’.