Richard W.M. Jones wrote: > > I'd like to know whether Gnulib developers would be interested in > > taking on an XDR implementation (based on the one in glibc)?
Yes, this definitely can have its place in gnulib, because it is glibc functionality that is not present on all other systems. You can look at the files doc/glibc-functions/xdr*.texi to get a feeling of it. As Richard said, many systems lack functions such as xdr_uint64_t. Whether you actually want it in gnulib, or add only hooks to gnulib so that it can use portableXDR when it is installed, is up to you. libintl and libiconv are in a similar situation: they implement functionality that is in glibc but not in other systems. But because of their size and self-containedness, it is better to distribute them as libintl.so and libiconv.so, rather than to include the source code in every program that needs it. > The request brings up the issue of what the limits of what can be in > gnulib. I'm not sure it is a useful discussion... My opinion: If it's "common" in the sense that more than one GNU package is likely to use the code, it's welcome in gnulib. And if it's a collection of small codes, rather than a big atomic chunk of code, it also technically makes sense to have it in gnulib. > Anyway, for example, > libtasn1 is used by GnuTLS, Shishi, and probably some other projects as > well, and I have thought about proposing parts of it as gnulib modules. > Probably the only reason I haven't done so already is because the code > is quite hard to read and maintain. Does it make more sense to have these packages installed as shared libraries, rather than shipped and linked into every application that needs it? Bruno
