Hi! Mark H Weaver <m...@netris.org> 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’.
