[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making libunistring optional

From: Noah Lavine
Subject: Re: Making libunistring optional
Date: Mon, 19 Nov 2012 19:43:35 -0500

Hi Mark,

I think you and Ludo may actually be thinking along similar lines. It seems like you're saying that you'd like one tarball that contains only Guile-specific code, and another one with Guile plus some dependencies plus maybe a nice build script.

I don't have an opinion on whether to separate the libunistring code from the main Guile repo, but I really really like the idea of bundling dependencies with Guile, and giving the users the option of whether to statically link Guile with them or dynamically link with system libraries. It's obviously not ideal, but I think it's a great idea for making Guile more portable. And I think it's the least bad way to help with dependencies.


On Mon, Nov 19, 2012 at 7:32 PM, Mark H Weaver <address@hidden> wrote:
Hi Ludovic,

address@hidden (Ludovic Courtès) writes:
> Here’s an attempt to “reduce the number of dependencies” of Guile.  The
> approach, as suggested by Bruno Haible, uses Gnulib’s
> ‘libunistring-optional’ module, along with the 22 (!) unistring modules
> that provide the functionality we need.
> When libunistring is available, it is used as before; when it’s not,
> those modules are built and linked into libguile.
> I had become convinced that this is a good idea, and a simple way to
> make our user’s lives easier.  Yet, this adds 184 source files to the
> tarball (would be more if we included tests), so I’d like to hear
> opinions.

Yikes!  It looks like this imports most of the libunistring source code
into Guile.

I think this is a bad idea.

If we simply want to save users the trouble of building and installing
our dependencies, how about creating a script to do the job for them,
analogous to jhbuild for Gnome?  Or perhaps distribute a "bundle" that
includes Guile and some key dependencies together in a single tarball,
along with a top-level build system that handles the combined build?

I'd really prefer to avoid importing large libraries like libunistring
directly into our source repository, or including them in our primary


reply via email to

[Prev in Thread] Current Thread [Next in Thread]