locale-related review, wcwidth() data

[Yuri Pankov]

Baptiste Daroussin wrote:
> 
> 5 déc. 2020 02:25:29 Thomas Munro <thomas.munro at gmail.com>:
> 
>> On Sat, Dec 5, 2020 at 2:31 AM Baptiste Daroussin <bapt at freebsd.org> wrote:
>>> I do like what I see here, the only reason I haven't review is that I can't
>>> test, since the last modification from hrs@ in the locale generation tools each
>>> time I try to regenerate the locales it fails.
>>
>> During install?  I noticed that too but wasn't sure of the correct fix, perhaps:
>>
>> diff --git a/tools/tools/locale/Makefile b/tools/tools/locale/Makefile
>> index 76fff6acb17..b6ae2feadac 100644
>> --- a/tools/tools/locale/Makefile
>> +++ b/tools/tools/locale/Makefile
>> @@ -95,7 +95,7 @@ install: install-${t}
>> install-${t}:
>>          cd ${LOCALESRCDIR}/${t} && \
>>              rm -f Makefile *.src && \
>> -           install -c ${t}/* ${LOCALESRCDIR}/${t}
>> +           install -c ${.OBJDIR}/${t}/* ${LOCALESRCDIR}/${t}
>> .  endif
>> .endfor
> 
> 
> Nope that one was easy to figure out, but once the locales are regenerated, localdef dies on plenty of them (non unicode mostly).

Now that you mentioned it, there's something I was thinking about for a 
long time now -- it's probably a sign that we need to mark all 
single-byte locales as set in stone, and stop regenerating the source 
for them as well as adding more and more workarounds against utf-8 
charmap.  This is something I'm going to look into eventually as I 
believe it will make updating to new CLDR releases much easier, that is, 
if I'm not missing something here.

> It does with the current setup as well as with an update of both cldr and un unicode