Re: Typo/oddity in realpath.texi

[Reuben Thomas]

On Fri, 20 Feb 2009, Bruno Haible wrote:

> Reuben Thomas wrote:
> > "Gnulib provides a module @samp{canonicalize-lgpl}"
> >
> > since there's a canonicalize and a canonicalize-lgpl module, shouldn't it
> > just say "a module @samp{canonicalize}", and users can make the usual guess
> > that there might be an LGPL version?
>
> The 'canonicalize' module is farther away from the realpath() function:
> Different API, and not usable in libraries due to xalloc(). I think mentioning
> 'canonicalize-lgpl' is therefore more adequate here.

How is the API different for canonicalize-lgpl, other than only declaring 
one function? It seems to use the same header file as canonicalize, which 
declares the GNU API canonicalize_file_name, which is documented as 
equivalent to realpath (foo, NULL).

The other differences are also a bit of a surprise, and to my mind are worth 
documenting. From reading the gnulib documentation, I generally expect, if I 
choose an LGPL version, simply to get the same code under a different 
license. Did I miss something? Or is canonicalize unusual in this respect?

In any case, it would seem worth documenting this, mainly because of the 
point about libraries. The obvious place would be in the canonicalize-lgpl 
module.

This seems a rather odd way to divide the code up, where a technical 
difference (xalloc) is hidden behind a license difference.

Would it make more sense to have a canonicalize module coming in two 
flavours, GPL and LGPL, and a GPL-only module canonicalize_mode which 
implements the extra APIs?

Forgive me if I've misunderstood something, but I hope it's at least obvious 
that there is a lack of clarity here, and I'm keen to help.

--
http://rrt.sc3d.org/ | wit, n.  educated insolence (Aristotle)