Re: new module: relpath

[Akim Demaille]

Hi Pádraig!

Le 16 juin 2012 à 18:15, Pádraig Brady a écrit :

> On 06/16/2012 04:25 PM, Bruno Haible wrote:
>> I agree that
>>  1. this is general-purpose functionality that has its place in gnulib,
>>  2. when you start to copy code from coreutils to bison, it's time to
>>     move it to gnulib, to avoid duplicate maintenance.
> 
> Me too. Thanks Akim for looking at this!

Please, feel very free to contribute :)  It's currently in akim/relpath.
Maybe you also have test cases?

>> About the module name 'relpath': The GNU standards, section "GNU Manuals",
>> say
>>   Please do not use the term "pathname" that is used in Unix
>>   documentation; use "file name" (two words) instead.  We use the term
>>   "path" only for search paths, which are lists of directory names.
>> 
>> Strictly speaking this is only about manuals, not about code. But the
>> more we use the term "file name" also in code, the less we are tempted
>> to misuse the term "path" in documentation. Gnulib already has modules
>>  concat-filename
>>  filename
>>  filenamecat
>> It would be good to choose a module name in this spirit.
> 
> I suppose relname would be most appropriate given that argument,
> though I think in this case it's slightly better to keep the relpath name
> so as to align with similar functions elsewhere like
> os.path.relpath() and relpath(1)?

I have no opinion, I will just do what I'm told to.

>> This module may produce error messages and be under GPL. Then the module
>> is not usable in shared libraries. If you want a module that is more widely
>> usable, consider an interface that returns error codes  or error strings,
>> remove the dependencies to 'error' and 'xalloc', and change the license
>> to 'LGPL'.

Pádraig, could you do that?  (I mean, the license part, though be
most welcome to handle the other issues :)