Re: About Guile crypto support

[Nala Ginrut]

On Sat, 2013-02-09 at 16:12 +0100, Ludovic Courtès wrote:
> Hi,
> 
> Daniel Hartwig <address@hidden> 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
>