Re: About Guile crypto support

[Mark H Weaver <mhw@netris.org>]

Hi Andy,

Andy Wingo <wingo@pobox.com> writes:

> On Sat 09 Feb 2013 16:12, ludo@gnu.org (Ludovic Courtès) writes:
>
>> 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.)
>
> I have the feeling that we should implement our own dynamic-link
> function without libltdl.  It would eliminate a dependency and allow us
> to use other search path rules, like ones that could deal with this
> case.  I think the situation would actually be better on other
> architectures because we wouldn't have to deal with bugs like this one:
>
>   http://thread.gmane.org/gmane.lisp.guile.bugs/5269

The problems we're having with libltdl are likely affecting many other
projects.  Wouldn't it be better to fix these problems in libltdl, to
the benefit of all its users, than for each of its users to duplicate
its functionality within their own projects?

More generally, I'm concerned with the direction we are being pressured
into by those who complain about the number of dependencies.  We ought
to look for better solutions than duplicating library functionality
within Guile's own source code.  Imagine if every program did that.
That way lies madness.

IMO, we ought to look for better solutions for those who complain about
dependencies.  One idea is to provide precompiled versions of Guile for
the major platforms (i.e. MinGW, MacOS and possibly also GNU/Linux) with
all dependencies included, for use by libguile-based projects that wish
to provide precompiled bundles for their users.  It might also make
sense to provide something along the lines of jhbuild to make the build
job easier for those who want more flexibility.

What do you think?

    Mark