[Nagiosplug-devel] Gnulib alternative?

Holger Weiss holger at CIS.FU-Berlin.DE
Fri Aug 22 18:33:59 CEST 2008


* Andreas Ericsson <ae at op5.se> [2008-08-22 17:34]:
> Holger Weiss wrote:
> > * Andreas Ericsson <ae at op5.se> [2008-08-22 17:09]:
> >> ton.voon at altinity.com wrote:
> >>> A more entrenched example would be GNU lib - we embed their code (at their
> >>> recommendation).
> >>
> >> While we're at it, I'm pretty much against this too. Plugins, weighing
> >> in at an average of 555.57 LoC, that can't be made to run without a
> >> rather large compatibility library need to be looked over. Especially
> >> when the functions gnulib typically provides are along the lines of
> >> strndup(), vasnprintf(), full_write() et al.
> > 
> > What's your suggestion?  Don't use non-essential stuff like asprintf()?
> > Or rewrite everything we need from Gnulib?  Or use something else than
> > Gnulib?  If so, what (and why)?  Or just forget about portability?
> 
> My suggestion is a combination of the above
> Try to work around the asprintf() stuff as much as possible. Since all
> plugins run single-threaded and only ever output stuff on stdout, most
> of the functionality can be implemented using multiple printf() calls
> instead. Everyone has printf().

In order to get rid of replacement code for asprintf(), we'd have to
restrict ourselves to _never_ use asprintf().  I wouldn't want to do
that just to get rid of replacement code which won't even be compiled on
most systems (since non-ancient Linux and BSD systems provide asprintf()
and friends in their libc's).

> Forgetting about portability is obviously not an option (although I
> love coding for a system where I know I have gcc-4.1 and glibc-2.8
> available everywhere), but adding a library of 1.7MB to 788KB of
> plugin code (not including tests) is just plain weird.

I have no idea why the plain fact that a library is larger than the code
which calls it would be "weird".

Most of the Gnulib stuff we use is either replacement code for functions
which should really be in libc but unfortunately isn't on some systems
we support, or stuff like e.g. portable access to filesystem data which
we definitely need but which is non-trivial to rewrite.  Maybe we could
get rid of some of the libc-replacement functions by abstaining from
using them, but I don't see any real benefit in doing so.

In any case, I don't agree that we should (or even could) get rid of
substantial parts of the code we currently use from Gnulib without
rewriting it. And IMO, we have far more important things to do than
rewriting Gnulib stuff.

Holger




More information about the Devel mailing list