It's a real shame we have to have that dummy po/Makefile.am One would have thought that because we have the AC_PROVIDE([AM_PO_SUBDIRS]) line it wouldn't be necessary.
On Sat, Mar 27, 2010 at 02:31:01PM -0700, Ben Pfaff wrote:
I pushed out my proposed changes to a new branch named
"proposed-gettext". It passes the testsuite.
Comments?
John Darrington <[email protected]> writes:
> Yes. I recall that was my primary complaint - it does (at least)
> two distinct things. At the time I didn't find a way to seperate
> them. If we can do that, then it might be worth considering using
> it again.
>
> On Fri, Mar 26, 2010 at 05:05:16PM -0700, Ben Pfaff wrote:
>
> AM_GNU_GETTEXT has two purposes. First, it figures out how to
> link against libintl. Second, it invokes AM_PO_SUBDIRS to set up
> all the po directory variables, etc.
>
> I think that it is only the second part that causes trouble, and
> I think that we can disable the second part by writing
> AC_PROVIDE([AM_PO_SUBDIRS])
> just above the call to AM_GNU_GETTEXT.
>
> I'll try this tonight, if I have time.
>
> > I don't think it will be very difficult to write an autoconf
> > test to see if libc contains libintl or not.
>
> The gettext manual makes it sound difficult. From the section
> titled "AM_GNU_GETTEXT in `gettext.m4'":
>
> The complexities that `AM_GNU_GETTEXT' deals with are the
following:
>
> * Some operating systems have `gettext' in the C library, for
example
> glibc. Some have it in a separate library `libintl'. GNU
> `libintl' might have been installed as part of the GNU
`gettext'
> package.
>
> * GNU `libintl', if installed, is not necessarily already in the
> search path (`CPPFLAGS' for the include file search path,
> `LDFLAGS' for the library search path).
>
> * Except for glibc, the operating system's native `gettext'
cannot
> exploit the GNU mo files, doesn't have the necessary locale
> dependency features, and cannot convert messages from the
> catalog's text encoding to the user's locale encoding.
>
> * GNU `libintl', if installed, is not necessarily already in the
run
> time library search path. To avoid the need for setting an
> environment variable like `LD_LIBRARY_PATH', the macro adds the
> appropriate run time search path options to the `LIBINTL' and
> `LTLIBINTL' variables. This works on most systems, but not on
> some operating systems with limited shared library support,
like
> SCO.
>
> * GNU `libintl' relies on POSIX/XSI `iconv'. The macro checks
for
> linker options needed to use iconv and appends them to the
> `LIBINTL' and `LTLIBINTL' variables.
>
> --
> Ben Pfaff
> http://benpfaff.org
--
Regarding a Microsoft/Xerox agreement:
"This is a match made in heaven.
Both companies excel at copying other people's work."
[email protected] <URL:http://slashdot.org/article.pl?sid=99/05/16/2211252>
--
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.
signature.asc
Description: Digital signature
_______________________________________________ pspp-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/pspp-dev
