Akim Demaille wrote:
> Before addressing other issues in my proposal, I would like to know
> if everybody agrees that being lgpl, being xalloc/error free, etc.
> is irrelevant for relpath?
Hi Akim,
You've hit the nail on the head.
Making this new module and all of its dependents xalloc/error-free
On 06/22/2012 06:02 AM, Akim Demaille wrote:
> Still, I have been asked to address many issues in relpath before
> a possible integration. One issue was making it library-ready,
> which I partly did by eliminating xalloc.h. But there are other
> issues, including the fact that relpath relies on
Hi Eli,
Le 19 juin 2012 à 17:51, Eli Zaretskii a écrit :
>> From: Akim Demaille
>> Date: Tue, 19 Jun 2012 14:15:19 +0200
>> Cc: Eric Blake ,
>> bug-gnulib@gnu.org
>>
>>> Maybe I'm looking at the wrong source file in gnulib. but I see these
>>> at the beginning of canonicalize_filename_mode:
>>>
> From: Akim Demaille
> Date: Tue, 19 Jun 2012 14:15:19 +0200
> Cc: Eric Blake ,
> bug-gnulib@gnu.org
>
> > Maybe I'm looking at the wrong source file in gnulib. but I see these
> > at the beginning of canonicalize_filename_mode:
> >
> > if (name == NULL)
> >{
> > errno = EINVAL;
> >
Le 18 juin 2012 à 18:31, Eli Zaretskii a écrit :
>> No, canonicalize_filename_mode is GPL because it calls xalloc() and dies
>> rather than return NULL.
>
> Maybe I'm looking at the wrong source file in gnulib. but I see these
> at the beginning of canonicalize_filename_mode:
>
> if (name == N
> Date: Mon, 18 Jun 2012 09:39:26 -0600
> From: Eric Blake
> CC: Akim Demaille , bug-gnulib@gnu.org
>
> >> + while (*path1 && *path2)
> >> +{
> >> + if (*path1 != *path2)
> >
> > This comparison should be case-insensitive for MS-Windows.
>
> Shouldn't normalization already guarantee c
On 06/18/2012 09:30 AM, Eli Zaretskii wrote:
>> At least to experiment on the concept, and on a suggestion from
>> Eric Blake weeks ago, I stole bits of the coreutils, and made them
>> a gnulib module.
>
> Perhaps the comments below, mainly related to portability to
> MS-Windows (but not only tha
> From: Akim Demaille
> Date: Thu, 14 Jun 2012 18:02:35 +0200
>
> In Bison, I consider computing relative paths between files
> (one concrete use is when the user creates the parser implementation
> file in --output=sub1/sub2/parser.c and the header file in
> --defines=sub3/sub4/parser.h, in whic
On 06/18/12 05:52, Eric Blake wrote:
+ realtarget = canonicalize_filename_mode (target, CAN_MISSING);
Indeed, for this to be LGPL, we would have to change
canonicalize_filename_mode() to have a looser license, and I'm not sure
it is a wise idea to attempt that.
Indeed, perhaps just blanket l
On 06/18/2012 05:38 AM, Akim Demaille wrote:
>>> >> +License:
>>> >> +GPLv3+
>> >
>> > 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 co
On 06/18/2012 04:02 AM, Akim Demaille wrote:
>> We really shouldn't be using malloc(PATH_MAX); there are platforms like
>> Hurd where it is undefined or extremely large (coreutils caps things to
>> avoid this issue), and you are wasting memory if it is even possible to
>> allocate this much. Furt
Hi Bruno,
I will address these issues step by step, time permitting.
Again, help is most welcome.
Le 16 juin 2012 à 17:25, Bruno Haible a écrit :
>> +++ b/modules/relpath
>
>> +Depends-on:
>> +canonicalize
>> +dirname
>> +error
>> +pathmax
>> +stdbool
>> +xalloc
>> +...
>> +License:
>> +GPLv3+
Le 14 juin 2012 à 18:55, Eric Blake a écrit :
>> +/* Return FROM represented as relative to the dir of TARGET.
>> + The result is malloced. */
>> +
>> +char *
>> +convert_abs_rel (const char *from, const char *target)
>> +{
>> + char *realtarget = canonicalize_filename_mode (target, CAN_MISSI
On 06/17/2012 10:54 AM, Bruno Haible wrote:
> Hi Pádraig,
>
>>> 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
On 06/17/2012 03:02 PM, Jim Meyering wrote:
> Akim Demaille wrote:
>> Le 16 juin 2012 à 17:25, Bruno Haible a écrit :
>>> Hi Akim,
>> Hi Bruno,
>> Thanks for the detailed comments.
> ...
+Depends-on:
+canonicalize
+dirname
+error
+pathmax
+stdbool
+xalloc
+..
Akim Demaille wrote:
> Le 16 juin 2012 à 17:25, Bruno Haible a écrit :
>> Hi Akim,
> Hi Bruno,
> Thanks for the detailed comments.
...
>>> +Depends-on:
>>> +canonicalize
>>> +dirname
>>> +error
>>> +pathmax
>>> +stdbool
>>> +xalloc
>>> +...
>>> +License:
>>> +GPLv3+
>>
>> This module may produce er
Hi Pádraig,
> > 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 si
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,
Le 16 juin 2012 à 17:25, Bruno Haible a écrit :
> Hi Akim,
Hi Bruno,
Thanks for the detailed comments.
> 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
On 06/16/2012 04:25 PM, Bruno Haible wrote:
> Hi Akim,
>
> Akim Demaille wrote:
>> In Bison, I consider computing relative paths between files
>> (one concrete use is when the user creates the parser implementation
>> file in --output=sub1/sub2/parser.c and the header file in
>> --defines=sub3/sub
Hi Akim,
Akim Demaille wrote:
> In Bison, I consider computing relative paths between files
> (one concrete use is when the user creates the parser implementation
> file in --output=sub1/sub2/parser.c and the header file in
> --defines=sub3/sub4/parser.h, in which case parser.c should include
> ".
On 06/14/2012 10:02 AM, Akim Demaille wrote:
> Hi all,
>
> In Bison, I consider computing relative paths between files
> (one concrete use is when the user creates the parser implementation
> file in --output=sub1/sub2/parser.c and the header file in
> --defines=sub3/sub4/parser.h, in which case p
Hi all,
In Bison, I consider computing relative paths between files
(one concrete use is when the user creates the parser implementation
file in --output=sub1/sub2/parser.c and the header file in
--defines=sub3/sub4/parser.h, in which case parser.c should include
"../../sub3/sub4/parser.h").
At l
23 matches
Mail list logo
