On 15.11.2015 18:17, John Marino wrote: >>>> See gettext-0.19.6/gettext-tools/configure, part started with >>>> # Test for the usual locale name. >>>> I don't have time to dig more such code now, but I remember I saw more >>>> for sure. > Of course it's the same topic. > If the configure of a port is affected by the locale, that's a big > problem. How is this not the same topic? This is environment problem, not presence or absence of some locales in the system (f.e. 8859-1 ones) we talked about. And can be easily fixed in the environment, unlike configure's silent script fallbacks, which can be fixed by recompiling only. About environment problem, we already have LANG=C somewhere in the /usr/ports/Mk/* (probably not in every place) and many ports set LANG=C or LC_ALL by themselves. > But I did look at gettext, which is configuring package based on what's > on the system (not environment). For the unicode checks, there is > obviously no issue. > > For the traditional checks, It's ironic, DragonFly uses short locales > like "fr_FR" which link to the approprioprate ISO8859 or UTF-8 locale. > Bapt removed them to avoid a bike shed and if he had not done that, this > gettext configure would not be an issue as "fr_FR" is the very first check. All parts are optional excepting language itself, so fr_FR is not short enough, but fr is. From POSIX: language[_territory][.codeset][_at_modifier] But I dislike short locales due to their uncertainty and remember some programs and shell scripts that attempts to parse locale name directly by itself for reasons I don't remember now. -- http://ache.vniz.net/Received on Sun Nov 15 2015 - 14:38:10 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:01 UTC