Re: installable gnulib library

[Eric Blake]

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?

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.

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.

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.

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.

-- 
Eric Blake