Re: [RFC PATCH 0/6] Enable building Gnu Global package on Hurd

On Wed, Jan 25, 2017 at 6:30 AM, Shigio YAMAGUCHI <[email protected]> wrote:
> Hi,
>> On digging futher[2][3], I came to the conclusion that instead of
>> defining PATH_MAX to a value, the way to fix it would be to change how
>> paths are handled. Although the changes are not difficult, one needs
>> to be careful to free the buffers when they are no longer
>> needed. Thought a bit tedious, the arguments against using PATH_MAX
>> (but also other similar macros) make sense.
>
> I agree with you.
>
>> Before applying the patch to the global package, I was hoping to get
>> some feedback and a view on whether they could be merged
>> upstream. There is nothing debian specific in the patches.
>
> I have committed the patches to the repository.
> Thank you for the better code.

Thanks for merging the patches. I'll upload a new package with them
until the next upstream release.

>
>> shows ~150+ locations where MAXPATHLEN is used. Is there interest to
>> address this? Would more such patches updating the code be useful?  Or
>> is there a better way to go about this?
>
> Such patches and guidelines are welcome.

That's good to know. Next time I'll pick such a task in global I'll
feel less hesitant. :)

Thanks,
Punit

> Thank you very much.
>
> Regards,
> Shigio
>
>
> 2017-01-24 7:43 GMT+09:00 Punit Agrawal <[email protected]>:
>>
>> Hi,
>>
>> Gnu Global package in Debian fails to build from source on Hurd[0] as
>> the build errors out when PATH_MAX is not defined. Here's the snippet
>> from libutil/find.c that triggers the failure -
>>
>> #ifndef PATH_MAX
>> #error Since this platform does not have PATH_MAX, you should define it
>> using an appropriate value for the platform.
>> /* #define PATH_MAX     1024 */
>> #endif
>>
>> On digging futher[2][3], I came to the conclusion that instead of
>> defining PATH_MAX to a value, the way to fix it would be to change how
>> paths are handled. Although the changes are not difficult, one needs
>> to be careful to free the buffers when they are no longer
>> needed. Thought a bit tedious, the arguments against using PATH_MAX
>> (but also other similar macros) make sense.
>>
>> In this series the dependency on PATH_MAX is dropped so that the build
>> succeeds on Hurd.
>>
>> Patches 1 & 2 are a couple of minor cleanups. Patch 3-5 update
>> instances where the macro is used. Patch 6 drops the offending snippet
>> above.
>>
>> Before applying the patch to the global package, I was hoping to get
>> some feedback and a view on whether they could be merged
>> upstream. There is nothing debian specific in the patches.
>>
>> I'd also like to take this opportunity to raise the larger question of
>> how to address similar issues elsewhere in the codebase. A quick grep
>> shows ~150+ locations where MAXPATHLEN is used. Is there interest to
>> address this? Would more such patches updating the code be useful?  Or
>> is there a better way to go about this?
>>
>> Feedback and opinions welcome.
>>
>> Thanks,
>> Punit
>>
>> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848302
>> [1]
>> http://cvs.savannah.gnu.org/viewvc/global/global/libutil/find.c?view=markup#l82
>> [2]
>> https://www.gnu.org/software/hurd/community/gsoc/project_ideas/maxpath.html
>> [3]
>> https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#PATH_MAX_tt_MAX_PATH_tt_MAXPATHL
>>
>> Punit Agrawal (6):
>>   libutil: Drop extraneous function declarations
>>   libutil: Staticize locally used functions
>>   libutil: Remove usage of PATH_MAX from getrealpath
>>   libutil: Remove usage of PATH_MAX from has_symlinkloop
>>   libutil: Convert rootdir to a dynamically allocated array
>>   libutil: Drop the requirement for PATH_MAX macro
>>
>>  libutil/find.c | 219
>> ++++++++++++++++++++++++++++++---------------------------
>>  1 file changed, 114 insertions(+), 105 deletions(-)
>>
>> --
>> 2.11.0
>>
>>
>> _______________________________________________
>> Bug-global mailing list
>> [email protected]
>> https://lists.gnu.org/mailman/listinfo/bug-global
>
>
>
>
> --
> Shigio YAMAGUCHI <[email protected]>
> PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3