From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel Subject: Re: About Guile crypto support Date: Sat, 9 Feb 2013 15:44:26 -0500 Message-ID: References: <1359896146.2754.19.camel@Renee-desktop.suse> <871ucvof60.fsf@gnu.org> <1360032192.2754.61.camel@Renee-desktop.suse> <87mwvisqwj.fsf@gnu.org> <878v6yojxg.fsf@gnu.org> <87sj55bjxz.fsf@gnu.org> <87mwvdwhcs.fsf@pobox.com> <87zjzd4br8.fsf@tines.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf307f37f4ec9f2904d550bdc2 X-Trace: ger.gmane.org 1360442674 11585 80.91.229.3 (9 Feb 2013 20:44:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Feb 2013 20:44:34 +0000 (UTC) Cc: Andy Wingo , =?ISO-8859-1?Q?Ludovic_Court=E8s?= , guile-devel To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Feb 09 21:44:54 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U4HI6-0000AU-6g for guile-devel@m.gmane.org; Sat, 09 Feb 2013 21:44:54 +0100 Original-Received: from localhost ([::1]:47770 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4HHm-0003At-V9 for guile-devel@m.gmane.org; Sat, 09 Feb 2013 15:44:34 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:54489) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4HHi-0003Ak-Ko for guile-devel@gnu.org; Sat, 09 Feb 2013 15:44:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U4HHg-0003J0-Ip for guile-devel@gnu.org; Sat, 09 Feb 2013 15:44:30 -0500 Original-Received: from mail-ve0-f173.google.com ([209.85.128.173]:58417) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4HHg-0003Io-Cm; Sat, 09 Feb 2013 15:44:28 -0500 Original-Received: by mail-ve0-f173.google.com with SMTP id oz10so4266055veb.4 for ; Sat, 09 Feb 2013 12:44:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=trSWee/mrZBVAJcOacJ8ZQ2lFi8phfFxVaZo25npdNc=; b=JFq8wh2wwNWQcopD0wMjgSdT1nuHpZZ8W83LaRlhou87Y54Rvv5MtPA9/y0Dx+lpWh m9nnsBKZbmt5wAEbDHM8fUiUcv2k8v/AYKOmBWMOCI3lyrHDFpaJtt0Ql7uj12LsFMrL 0w4+7yL9dOeZJexBU3WGR6y+xZoqjZlAJHqV68qXNyjDozeG/C9LCpefiy/pefQvXyng l7Jg2NHPA0ZxGq7pQKOSCp8EFE4yerm0YBr5KnxOjrEfbllvO8dkVnlIDRPzXSHCZNbJ qrUGGzUXtRK4fjekUbbYGOiaD0Em23ZH6ohJUxe9jjUhAkHUK1dwcS/yF15b9Uyd92VV FmjA== X-Received: by 10.52.89.52 with SMTP id bl20mr10849454vdb.85.1360442667343; Sat, 09 Feb 2013 12:44:27 -0800 (PST) Original-Received: by 10.58.171.41 with HTTP; Sat, 9 Feb 2013 12:44:26 -0800 (PST) In-Reply-To: <87zjzd4br8.fsf@tines.lan> X-Google-Sender-Auth: yl0He14L7IY59tIRL3KyqLpFi5Y X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.128.173 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:15718 Archived-At: --20cf307f37f4ec9f2904d550bdc2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Mark, I agree with everything you said about dependencies. I think the real solution is something like what you said - sharing code, but bundling. One way to push that farther would be to distribute tarballs that include the complete source of some libraries, and somehow making a combined build system that configures and builds all of them. I would nominate libgc for this, since we keep hitting trouble with new or old libgc versions. Noah On Sat, Feb 9, 2013 at 12:50 PM, Mark H Weaver wrote: > Hi Andy, > > Andy Wingo writes: > > > On Sat 09 Feb 2013 16:12, ludo@gnu.org (Ludovic Court=E8s) writes: > > > >> An issue with the FFI is distros where .la and .so files are only > >> available in the -dev package, because then =91dynamic-link=92 won=92t= 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 > > --20cf307f37f4ec9f2904d550bdc2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Mark,

I agree with everything you said = about dependencies. I think the real solution is something like what you sa= id - sharing code, but bundling.

One way to push t= hat farther would be to distribute tarballs that include the complete sourc= e of some libraries, and somehow making a combined build system that config= ures and builds all of them. I would nominate libgc for this, since we keep= hitting trouble with new or old libgc versions.

Noah
On Sat, Feb 9, 2013 at 12:50 PM, Mark H Weaver = <m= hw@netris.org> wrote:
Hi Andy,

Andy Wingo <wingo@pobox.com> w= rites:

> On Sat 09 Feb 2013 16:12, ludo@gnu.org= (Ludovic Court=E8s) writes:
>
>> An issue with the FFI is distros where .la and .so files are only<= br> >> available in the -dev package, because then =91dynamic-link=92 won= =92t 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. =A0It would eliminate a dependency and allow= us
> to use other search path rules, like ones that could deal with this > case. =A0I think the situation would actually be better on other
> architectures because we wouldn't have to deal with bugs like this= one:
>
> =A0 http://thread.gmane.org/gmane.lisp.guile.bugs/5269

The problems we're having with libltdl are likely affecting= many other
projects. =A0Wouldn'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. =A0We ought to look for better solutions than duplicating library functionality
within Guile's own source code. =A0Imagine if every program did that. That way lies madness.

IMO, we ought to look for better solutions for those who complain about
dependencies. =A0One 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. =A0It 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?

=A0 =A0 Mark


--20cf307f37f4ec9f2904d550bdc2--