guile-devel
[Top][All Lists]
Advanced

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

Re: Making libunistring optional


From: Mark H Weaver
Subject: Re: Making libunistring optional
Date: Mon, 19 Nov 2012 19:32:44 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

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
tarballs.

    Regards,
      Mark



reply via email to

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