Re: installable gnulib library

[Gary V. Vaughan]

Hi Eric,

Thanks for the feedback.

On 27 Sep 2008, at 01:04, Eric Blake wrote:

> Gary V. Vaughan <gary <at> gnu.org> writes:
> > I have an (undoubtedly caffeine induced) idea... why not enhance
> > gnulib to provide a shim that sits between the system libraries and
> > client code that wants to use it without shipping (another copy) of
> > the particular parts it depends upon?
>
> I am somewhat skeptical of this idea, for sevaral reasons.
>
> Gnulib mutates too quickly.  How would you guarantee that the  
> interface the
> user installed on their system is new enough to meet your package's  
> needs,
> particularly when you look through NEWS at how often gnulib  
> interfaces change?

Yes, and actually, that bugs me quite a lot.  While gnulib is still  
finding
its feet, that's still acceptable, but at some point (the core  
interfaces of)
gnulib really ought to settle down.  And I've moaned on and off that  
it really
would be very nice (for the sake of being able to rebuild old tarballs  
of
gnulib client releases at least) if gnulib made an occasional formal  
release.

> Gnulib includes a LOT of source code hacks (witness all the  
> #include_next
> header replacements).  A library only solves API needs, but it does  
> not solve
> source code needs, so packages will still end up shipping lots of  
> code from
> gnulib.  It's easier to ship all of the source code, than to try and  
> pick out
> the parts not already covered by an installed library.

That's a good point.

Are any of the modules that do that core functionality?  Is there any  
means
to provide the same functionality without the source code hacks?  If  
not,
maybe it is still a win to have gnulib installed as a library, plus a  
small
amount of the essential glue that packages can choose to add instead  
of the
whole 2MiB of autoconf support code?

> Think about gnulib-tool --avoid - how does one exclude entry points  
> from an
> installed library, if they explicitly want to avoid a particular  
> gnulib module
> (for example, because of licensing incompatibility).  Source code  
> distribution
> makes this task a lot easier.

I'm not proposing that we disregard the current system and replace it  
with
an installed library!  Merely that there is an option to install  
gnulib (or
in light of your observations, some core part of gnulib) so that client
packages can choose between full on source code integration plus  
autotools,
or in some cases be able to rely on just the installed gnulib and some
Makefiles.

> In that vein, not all gnulib modules play together nicely.  For  
> example, just
> from today, vasnprintf now behaves differently on mingw depending on  
> whether
> you are also using sigpipe-die, and this difference is at the source  
> code level
> (faking SIGPIPE on mingw comes with a lot of baggage).  The choice  
> to use
> sigpipe-die is a conscious decision of the maintainer, but if gnulib  
> were
> installed, then you would have to have multiple library versions to  
> expose
> parameterization to what used to be a compile-time decision.

Bleh.  That's a tough one for sure.  But not enough to discourage me  
from
trying just yet :)

> I think http://www.gnu.org/software/gnulib/manual/gnulib.html#Introduction
> covers most of these points, as well as mentioning the difficulty in  
> trying to
> make libiberty an installable library as precedent for the paradigm  
> of keeping
> gnulib source-only.

Even having reread that, I don't think there's any reason not to try to
find a line between what parts of gnulib can reasonably go into an  
installed
library, and what parts are complex enough that they require configure  
time
assistance to work on the host system.

Cheers,
        Gary
--
Email me:          address@hidden                        (\(\
Read my blog:      http://blog.azazil.net              ( o.O)
And my other blog: http://www.machaxor.net              (uu )o
...and my book:    http://sources.redhat.com/autobook  ("("_)