Re: [PATCH] improve locale handling in m4/wcwidth.m4

[Bruno Haible]

Hello,

kc wrote:

> However, I was cross-compiling gettext-0.17 on x86_64-pc-linux-gnu for  
> i686-pc-linux-gnu. gettext did not compile because it did not use the  
> system wchar.h, but some other variant provided with the gettext's source  
> tarball. The cause was that gettext's configure was “guessing no” when  
> checking whether or not wcwidth would work for my cross i686-pc-linux-gnu.

The patch below should fix it. We can assume that wcwidth works on glibc
systems.

> The test in the m4 file assumes that any wcwidth works. Unless it can load  
> the “fr_FR.UTF-8” locale. Then it performs a simple tests.

Yes. This is sufficient for detecting the problem on MacOS X.

> Nevertheless, the (unpatched) m4/wcwidth.m4 looks severly flawed.
> It assumes that any wcwidth works. Unless it can load the “fr_FR.UTF-8”  
> locale. Then it performs a simple tests. ... find some  
> canonical way to find _any_ UTF-8 locale and then use this locale instead  
> of fr_FR.UTF-8?

Your suggestion would lead to a correct autoconf test as well. But we try
to make configure tests fast - run as few programs as possible, skip
unnecessary tests. There's no big point in making the MacOS X test work
in a 100% robust way on Cygwin and Solaris - because Cygwin and Solaris
are likely to have different bugs regarding wcwidth (if they would have
one at all).

When some UTF-8 locale exists, we need to check for the MacOS X bug.
When not, wcwidth does not apply to Unicode characters anyway.

> What if I'd sit on a platform *without* a properly working UTF-8 and  
> remove the fr_FR.UTF-8 locale?

Then, after you built the program, you shouldn't complain that it does
not work optimally in el_GR.UTF-8 locales.

> > There is a hidden assumption that a system either has many UTF-8
> > locales [...] or none at all [...]
> 
> This hidden assumption fails for me. And I'd argue that I am not the only  
> one (E.g.: gentoo encourages people to only build the locales they use  
> [1]).

OK, I've taken out glibc systems from this assumption.

Bruno


2009-07-14  Bruno Haible  <address@hidden>

        * m4/wcwidth.m4 (gl_FUNC_WCWIDTH): Guess it works on glibc systems.
        Reported by anonymous kc.

--- m4/wcwidth.m4.orig  2009-07-14 21:31:22.000000000 +0200
+++ m4/wcwidth.m4       2009-07-14 21:29:16.000000000 +0200
@@ -1,5 +1,5 @@
-# wcwidth.m4 serial 14
-dnl Copyright (C) 2006-2008 Free Software Foundation, Inc.
+# wcwidth.m4 serial 15
+dnl Copyright (C) 2006-2009 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
 dnl with or without modifications, as long as this notice is preserved.
@@ -7,6 +7,7 @@
 AC_DEFUN([gl_FUNC_WCWIDTH],
 [
   AC_REQUIRE([gl_WCHAR_H_DEFAULTS])
+  AC_REQUIRE([AC_CANONICAL_HOST]) dnl for cross-compiles
 
   dnl Persuade glibc <wchar.h> to declare wcwidth().
   AC_REQUIRE([AC_USE_SYSTEM_EXTENSIONS])
@@ -68,7 +69,15 @@
       return 1;
   return 0;
 }], [gl_cv_func_wcwidth_works=yes], [gl_cv_func_wcwidth_works=no],
-          [gl_cv_func_wcwidth_works="guessing no"])
+          [
+changequote(,)dnl
+           case "$host_os" in
+                     # Guess yes on glibc systems.
+             *-gnu*) gl_cv_func_wcwidth_works="guessing yes";;
+             *)      gl_cv_func_wcwidth_works="guessing no";;
+           esac
+changequote([,])dnl
+          ])
       ])
     case "$gl_cv_func_wcwidth_works" in
       *yes) ;;