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 :)
