On Sat, 2013-02-09 at 16:12 +0100, Ludovic Courtès wrote: > 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.)unanimous >
This could be a real issue since almost all mainstream distros packaging policy force *.so be put in -devel packages. Though openSUSE/debian adds the exception for Guile, I believe it's so hard to do that for every packages uses Guile. Considering Guile would exists in every GNU project (in principle), the issue may break the packaging policy totally. @andy: But I do like to have our own dynamic-link without libltdl, which will be interesting and a study chance for me . ;-) And maybe it'll be blamed for reinventing wheels? > Thanks, > Ludo’. > > [0] http://git.sv.gnu.org/cgit/libchop.git/tree/guile2/chop/internal.scm#n130 >
