Re: Bug#353435: Patch for gettext.m4 to remove superfluous operations (fwd)

[Ron]

Hi,

On Tue, Feb 21, 2006 at 12:46:17PM +0100, Bruno Haible wrote:
> Ron <address@hidden> wrote:
> > The second hunk is just an extension of the first, removing
> > excess output from the configure run.  All the information
> > given there is already reported by code above in the same
> > macro.  It only sets the gt_source variable, which is not used
> > anywhere else.
> 
> This "excess output" is desired. The previous configure messages
> ("checking for GNU gettext in libc", "checking whether to use NLS",
> "checking for GNU gettext in libintl" etc.) all check for some
> partial bits of information. A decision is then made where to take
> the gettext() function from. This decision is a complicated combination
> of the previous pieces of information. It helps me while debugging the
> error reports from people on various platforms to see this final choice
> printed explicitly.

Yes, I initially assumed that something like this was the case,
but I'm afraid I (still) can't see anywhere that would make the
second set report anything different than the first.

> You might think that
> 
> ++> checking for GNU gettext in libc... yes
> ++> checking where the gettext function comes from... libc
> 
> is redundant. It is not. There are cases when a GNU gettext() function
> is found in libc but will not be used (such as when the configure.ac
> requests some features that the function in libc doesn't have, or when
> --with-included-gettext was given on the command line).

Tracing the places where the state of the salient variables change
would seem to indicate that even though the tests are complicated,
the results are not (any longer??) very prone to fluctuation.  In
fact I can't find a single place where gt_use_preinstalled_gnugettext,
gt_cv_func_gnugettext_libc, or gt_cv_func_gnugettext_libintl changes
its state once set.  Is there another that might tip the scales there?

If it really is still useful, I'm not too fussed about keeping it,
mostly it looked to me (and still does) like something that was
useful in the past, but improvements around it have made it redundant.


Oh, and at the risk of bad form, I've got a one liner, two place patch
for libiconv which enables it to build out of the box with mingw(-cross).
Running on the presumption that: a) its a no brainer, and b) Bruno is
the right person for it to end up with;  I've attached it below.

All it does is ensure the windows api symbols that are used in that
#if block, are actually defined.  Presumably VC++ always includes them
as a convenience in case you 'forget' or something.
Assuming it's ok too, we can close the whole lot together, if not, we
can forward it somewhere more appropriate...

cheers!
Ron


diff -ru libiconv-1.9.1.orig/lib/relocatable.c libiconv-1.9.1/lib/relocatable.c
--- libiconv-1.9.1.orig/lib/relocatable.c       2003-04-05 19:33:25.000000000 
+0930
+++ libiconv-1.9.1/lib/relocatable.c    2006-02-16 20:04:53.000000000 +1030
@@ -273,6 +273,8 @@
 
 #if defined _WIN32 || defined __WIN32__
 
+#include <windows.h>
+
 /* Determine the full pathname of the shared library when it is loaded.  */
 
 BOOL WINAPI
diff -ru libiconv-1.9.1.orig/libcharset/lib/relocatable.c 
libiconv-1.9.1/libcharset/lib/relocatable.c
--- libiconv-1.9.1.orig/libcharset/lib/relocatable.c    2003-04-05 
19:33:25.000000000 +0930
+++ libiconv-1.9.1/libcharset/lib/relocatable.c 2006-02-16 20:03:32.000000000 
+1030
@@ -273,6 +273,8 @@
 
 #if defined _WIN32 || defined __WIN32__
 
+#include <windows.h>
+
 /* Determine the full pathname of the shared library when it is loaded.  */
 
 BOOL WINAPI