Hi, Daniel Hartwig <mand...@gmail.com> skribis:
> By the way, I very much like the conventions used in the GnuTLS > bindings. The enums in particular make a lot of sense for a security > library, with the extreme type safety they provide. I will pursue a > similar approach. Yeah, I think it’s helpful. > One question. With the current state of FFI, do you think it matters > much whether the bulk of the bindings are done in C or FFI? I think it depends on the amount of public C structs, enums, inlines, and constants, and how often they are changed. When there are too many of them and they are subject to change, it might be easier to use C (though that can be worked around from the FFI by calling the C compiler, as in [0].) My impression is that libgcrypt uses mostly opaque pointer types and has a stable API, so the using FFI should be just fine. An issue with the FFI is distros where .la and .so files are only available in the -dev package, because then ‘dynamic-link’ won’t work unless that -dev package is installed (as recently discussed on guile-user.) Thanks, Ludo’. [0] http://git.sv.gnu.org/cgit/libchop.git/tree/guile2/chop/internal.scm#n130
