bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: modules for generic unordered sets and mappings


From: Bruno Haible
Subject: Re: RFC: modules for generic unordered sets and mappings
Date: Fri, 2 Jul 2010 16:01:10 +0200
User-agent: KMail/1.9.9

Hi Paolo,

> I disagree that all these should be in gnulib.  In fact, I think ADTs 
> don't belong there.

Why not? The '*-list' modules are used by gettext, m4, pdf, the 'clean-temp'
module, git-merge-changelog. They clearly satisfy the gnulib entry criterion
of " "portability" and/or common files for GNU projects ". I expect the
'*-set' and '*-map' to be used in the same way.

> Maintenance and, secondarily, RAM cost.

Maintenance? For the *-list modules, there were 0 changes in 2010 so far,
3 changes in 2009, 1 in 2008, 2 in 2007. This is not a lot.

RAM cost? Do you think linking with a shared library with 100 modules costs
less RAM than having 5 of these modules linked in the executable? Also, do
you frequently run 'm4' at the same time as you view PDF files or run
'msgfmt'? I think, in the current situation, linking with a non-shared library
is still perfectly fine.

> libunistring and crypto stuff are borderline  
> already (because some of the modules actually make sense in gnulib, e.g. 
> uniwidth and sha1), but these should be in a shared library, not a 
> static one.

You have seen (on the occasion of libunistring) that when there is enough
demand for having the code in the form of a shared library, we can release
the code in this form, while still keeping it available in gnulib. For the
moment, however, no one has asked for having the '*-list' modules in a
shared library.

> In fact, glib or libnih probably provide all that you need already

Yes, there are many libraries that provide some kind of container data
structure: avl, gdsl, libast, libh, libmba, libscl, libslacj, libtc, libuniqx,
sglib, skalibs, and many others.

None of these libraries provide the containers as _abstract_ data types.
Always only concrete data types, with a different API for different list types.

Also, the reason I try not to use glib is that its error/bug handling is too
relaxed (prints a message to stderr, but no easy way to debug it), its
thread implementation is partially overkill (the condition variables, I mean),
and the autoconf macro for linking with it is non-trivial.

Also, libnih is under GPLv2, not GPLv2+.

Bruno



reply via email to

[Prev in Thread] Current Thread [Next in Thread]