Re: xgettext with UI files support

[Richard PALO <richard%netbsd.org@localhost>]

Le 17/06/15 23:39, Richard PALO a écrit :
> Le 17/06/15 17:42, Ryo ONODERA a écrit :
>> Hi,
>>
>> From: Richard PALO <richard%netbsd.org@localhost>, Date: Tue, 16 Jun 2015 12:13:34 +0200
>>
>>> Le 15/06/15 17:00, Ryo ONODERA a écrit :
>> (snip)
>>>
>>> It looks like there are plenty of us working on gettext lately!
>>>
>>> Perhaps this should be all overhauled, as there is another issue that needs addressing
>>> namely the fact that configure scripts frequently look for the g' prefixed flavours of
>>> the programs as well (in order to avoid a mix of pkgsrc and native gettext being used as
>>> currently is frequently the case, for example, on SunOS).
>>>
>>> The easy part is converting gettext-tools to do like GNU binutils or diffutils and
>>> put the g' flavour in bin with symlinks in $PKGGNUDIR/bin, but the TOOLS also need to do the right thing.
>>>
>>> Can we do this a bit more formalistic?
>>
>> Could you provide me any hint about what problem is fixed with g-prefix?
>>
>> Thank you.
>>
>>> -- 
>>> Richard PALO
>>>
> 
> most solaris platforms traditionally have *at least* native gettext, msgfmt, and xgettext
> in /usr/gnu/bin and g-prefixed binaries in /usr/bin.
> 
> The problem to be fixed is when pkgsrc gettext-tools should be used, but
> with the g-prefix, GNU configure can pick up native for those *and then*
> pkgsrc gettext for the rest.
> 
> For a example, take a look at databases/gnome-mime-data wrt gmsgfmt.
> 
> cheers
> 

FWIW, my work-in-progress is :
http://www.netbsd.org/~richard/gettext-tools.diff
http://www.netbsd.org/~richard/gettext.mk.patch

gettext.mk.patch doesn't [yet] add any other frequently used
gettext tools but now does the alias for pkgsrc g-prefix tools.

gettext-tools.diff has some test specific things (gt_cv_locale_fr and asprintf)
and uses pkgsrc libxml2 instead of the included one, but now does the PKGGNUDIR thing.

Hopefully there is interest in something along these lines after the
quarterly drop.
-- 
Richard PALO