Re: Making libunistring optional

[Ludovic Courtès]

Hi!

Mark H Weaver <address@hidden> skribis:

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

It’s not “most of” libunistring.  In terms of modules, it may be less
than half of the modules that compose libunistring.

But it’s definitely a big chunk of code.

> 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?

Like APT, or RPM, or Guix, or...?  :-)

> 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?

How’s that different from using Gnulib modules?

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

These are 2 separate issues actually.

Regarding the former, we currently include Gnulib source files into our
repo.  We could instead use a Git submodule for Gnulib, and have a fancy
bootstrap script that runs ‘gnulib-tool --update’.  This is what
Coreutils does.  I think we’ll have to do it anyway, because the current
way of doing things is tedious and clutters our repo.

The latter is a different issue.  After all, I’m not strictly against
shipping additional code in tarballs, if users really think it’s
valuable.

Now, we could perhaps reduce our dependency on Gnulib.  Of those 22
modules, some are used just in a single place, like unistdio.  If it
turns out that libunistring can be avoided in such cases, with no loss
of functionality and no duplication, then things may be more reasonable.

Is anyone willing to look into this?  :-)

Thanks,
Ludo’.