GNOME Bugzilla – Bug 59386
Resolve gettext dependency on Win32
Last modified: 2011-02-18 15:48:02 UTC
For the win32 and other port that don't have a gettext implementation I've made a patch that implements this in glib. It also adds the gettext API to glib, prefixed with "g_". Patch found at: http://lists.gnome.org/archives/gtk-devel-list/2001-August/msg00484.html
I think having a gettext() implementation that can be counted on on all platforms is pretty necessary. Still some questions of the details of this patch and whether a patch like this is the best way to go about it.
GNU gettext is now LGPL, so on Unix this is resolved with: Wed Sep 19 11:23:41 2001 Owen Taylor <otaylor@redhat.com> * configure.in: Error out if gettext support is not found. (#59386) On Win32, we may need to include an implementation of gettext or else the gettext will need to be fixed to build out of the box on Win32.
Dunno if it's important, but autogen.sh will fail (uncleanly) if gettext isn't installed, because acinclude.m4 depends on some m4 macros that gettext installs.
GNU gettext works fine on Windows. Whether it can be said to build out of the box is another matter. There are some fetures that really are useful on Windows that aren't in the official sources.
Moving 2.0.1 Win32 bugs to 2.0.2 milestone.
Mon May 13 23:20:00 2002 Owen Taylor <otaylor@redhat.com> * autogen.sh (have_gettext): Add a check for GNU gettext. (Pointed out by Dan Winship in #59386.) Closing bug. it would be good if any useful win32 additions got into the upstream gettext, but that really doesn't need to be in the Glib bug tracker.
The change above is breaking build on newest Solaris version where GNU gettext package is not really required. There I'd like to use native gettext stuffs except xgettext command rather than GNU gettext stuffs, since its /bin/msgfmt, /bin/gettext, and al of gettext functions in system's libc.so are GNU compatible (while only xgettext command is not so for some techinical reason). But if 'xgettext --version' failes in autogen.sh, there is no chance to use any of the system's gettext stuffs. As far as I understand --version command is not requirement for xgettext standard options in Li18nux2000 spec. Also, each of gettext functon is individually checked in configure script, anyway, even without this change. Moreover, in normal 'make all' and 'make install', xgettext is not really needed for most people except when people want to extract messages from sources for some reason. Can you please back out this change? For windows, it may be workaround only if GNU gettext m4 macros are found at aclocal's path.
Does solaris install the same autoconf macros as GNU gettext???? If not, the only way to make autogen.sh work without GNU gettext installed would be to put the macros in acinclude.m4 But it couldn't have worked before this change either. (this part has nothing to do with WIndows)
I put these gettext.m4, lcmessage.m4, and progtest.m4 locally like $(HOME)/share/aclocal/ subdirectory and set ACLOCAL_FLAGS="-I $(HOME)/share/aclocal". Before doing this, I also tried to put these macros into acinclude.m4, but failed for unknown reasons. (I'm not really sure if I did this on glib, but maybe I did on some other module. I'll try this on glib.)
I ran glib build, without GNU gettext and without this autogen.sh change, then autogen.sh failed as expected. It could not resolve two aclocal macros - AM_PATH_PROG_WITH_TEST and AM_LC_MESSAGES. Then, I copied these two macros in the lcmessage.m4 and progtest.m4 of GNU gettext 0.10.40 package over into glib/acinclude.m4. This time, autogen.sh works well, and configure, and make all, make install also goes well. (I actually did just ~/bin/modmake.sh glib.) Should it work well on Windows, then can we go with this, instead of xgettext --version check?
autogen.sh also fails other Gnome2 modules if their acinclude.m4 refer to AM_PATH_PROG_WITH_TEST and AM_LC_MESSAGES and autoconf macros for GNU gettext are not installed. I've seen it happen in gtk+, ggv, gedit, gconf, and bonobo-activation. At least in gtk+, putting these macros into acinclude.m4 worked around as well as it did in glib.
opened #81885 with OS=Solaris.