Re: [PATCH][gnulib] Add the Sframe package

[Bruno Haible]

[Adding back Weimin to CC.]

Jeffrey Walton wrote:
> I don't think it's a good idea to subsume libbacktrace and libunwind
> into Gnulib.
> 
> First, from another project's point of view, the dependency has not
> changed. A dependency still exists. It has just moved around.
> 
> Second, I'm guessing other projects may want libbacktrace or libunwind
> without the Gnulib dependency. Gnulib is non-trivial to incorporate
> into a project. That's a lot of extra maintenance costs for other
> projects.

AFAIU, the authors of libsframe have decided that they want libsframe to
be consumable in two ways:
  - as a regular library,
  - as a source-code library, for those packages that don't want yet another
    library dependency.

That's their - valid - choice. In fact, it is the same choice I made for
libunistring in 2009.

If a consumer finds that the source-code library approach, with an
integration via gnulib-tool, is too complex for them, they will happily
use the binary library in .so format.

> Third, libbacktrace and libunwind are extra maintenance for the Gnulib
> folks. It is an extra drain on your limited development cycles.
> 
> Finally, libunwind has some troubles on non-Linux platforms. I'm
> pretty sure MacPorts is still waiting for a libunwind that works with
> modern Clang and C++. I don't think it's fair to the Gnulib folks to
> inherit problems like that.

Jeff, thanks for these ideas. I tend to agree with you that it would be
unwise for Gnulib to adopt code or problems if the respective maintainers
then become unresponsive.

Then, how about if the libsframe authors create a separate git repository
in which they add the new 2 or 3 Gnulib modules, with exactly the same
directory and file structure as it would be in Gnulib? To consume such a
git repository, is not much more complex than consuming it in Gnulib:

  - Instead of having one git submodule 'gnulib', the consumer will have
    2 git submodules 'gnulib' and 'sframe'.

  - In autogen.sh, instead of calling 'gnulib/gnulib-tool ...', they will
    call 'gnulib/gnulib-tool --local-dir=sframe ...'. Just one added command-
    line argument.

Since it will be their git repository, the burden of maintaining the sframe
code will not fall on us (the Gnulib people).

The '--local-dir' option is well-tested: GNU gettext, GNU make, GNU guile
make use of it already.

This approach will also be adopted by other packages rather soon: I have a
package in the works for which Gnulib modules are the perfect structure, but
which is too specialized for being included *in* Gnulib proper.

Weimin, what do you think about this proposal?

Bruno