AM_GNU_GETTEXT weirdness

AM_GNU_GETTEXT weirdness

[Marius Vollmer]

Hi,

running ./autogen.sh now runs gettextize and that causes some
'useless' things to happen, like the creation of po/ and the inclusion
of po/Makefile.in in _all_ AC_CONFIG_FILES statements in configure.in.

I guess all this happens for the benefit of programs that want to
internationalize/localize themselves.  Right?  Do we need po/?

Worse, automake now fails with:

  Makefile.am:26: AM_GNU_GETTEXT used but `po' not in SUBDIRS

Including po in SUBDIRS results in

    Making all in po
    make[2]: Entering directory `/home/mvo/work/guile/guile-core/po'
    make[2]: *** No rule to make target `all'.  Stop.
    make[2]: Leaving directory `/home/mvo/work/guile/guile-core/po'
    make[1]: *** [all-recursive] Error 1
    make[1]: Leaving directory `/home/mvo/work/guile/guile-core'
    make: *** [all] Error 2

So what should we do?  Include po in SUBDIRS or somehow cope without
AM_GNU_GETTEXT?


Simply wrapping gettext and friends turns out to have a much larger
effect than I thought.  I fully expect that there are people out there
without gettext and Guile will not build for them.  What then?
Include libintl in Guile?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: AM_GNU_GETTEXT weirdness

[Jan Nieuwenhuizen]

Marius Vollmer writes:

> running ./autogen.sh now runs gettextize and that causes some
> 'useless' things to happen, like the creation of po/ and the inclusion
> of po/Makefile.in in _all_ AC_CONFIG_FILES statements in configure.in.

>   Makefile.am:26: AM_GNU_GETTEXT used but `po' not in SUBDIRS

None of this happens here, what version of automake do you use?

> I guess all this happens for the benefit of programs that want to
> internationalize/localize themselves.  Right?

I have no clues whatsoever about what the developers of auto* have in
mind.  You'll have to ask Bruno about the AM_GNU_GETTEXT/libintl stuff.
What I had initially, was

    dnl i18n tests
    AC_CHECK_HEADERS([libintl.h])
    AC_CHECK_FUNCS(gettext)
    if test $ac_cv_func_gettext = no; then
       AC_CHECK_LIB(intl, gettext)
    fi
    AC_CHECK_FUNCS([bindtextdomain textdomain])

maybe something like that is better?

> Simply wrapping gettext and friends turns out to have a much larger
> effect than I thought.  I fully expect that there are people out there
> without gettext and Guile will not build for them.  What then?

That's why I was a bit reluctant about writing a patch for Guile,
instead of only for gettext, which was all I needed.  Anyway, this is
for the better, and Guile should build without gettext and without
libintl, of course.  A problem is that I don't have a development
machine without these, so I couldn't test.

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: AM_GNU_GETTEXT weirdness

[Marius Vollmer]

[ Bruno, the gettext patch does not fit entirely smoothly.  I have
  CCed you on the discussion, hopefully you can help.
]

Jan Nieuwenhuizen <janneke@gnu.org> writes:

> Marius Vollmer writes:
>
>> running ./autogen.sh now runs gettextize and that causes some
>> 'useless' things to happen, like the creation of po/ and the inclusion
>> of po/Makefile.in in _all_ AC_CONFIG_FILES statements in configure.in.
>
>>   Makefile.am:26: AM_GNU_GETTEXT used but `po' not in SUBDIRS
>
> None of this happens here, what version of automake do you use?

I have just upgraded to 1.9, with identical results.

>> I guess all this happens for the benefit of programs that want to
>> internationalize/localize themselves.  Right?
>
> I have no clues whatsoever about what the developers of auto* have in
> mind.  You'll have to ask Bruno about the AM_GNU_GETTEXT/libintl stuff.
> What I had initially, was
>
>     dnl i18n tests
>     AC_CHECK_HEADERS([libintl.h])
>     AC_CHECK_FUNCS(gettext)
>     if test $ac_cv_func_gettext = no; then
>        AC_CHECK_LIB(intl, gettext)
>     fi
>     AC_CHECK_FUNCS([bindtextdomain textdomain])
>
> maybe something like that is better?

Bruno, what is your view?

>> Simply wrapping gettext and friends turns out to have a much larger
>> effect than I thought.  I fully expect that there are people out there
>> without gettext and Guile will not build for them.  What then?
>
> That's why I was a bit reluctant about writing a patch for Guile,
> instead of only for gettext, which was all I needed.  Anyway, this is
> for the better, and Guile should build without gettext and without
> libintl, of course.  A problem is that I don't have a development
> machine without these, so I couldn't test.

I have a hard time convincing myself now that gettext support should
be in the core, when I have, for example, not accepted SCTP.  Hmm.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: AM_GNU_GETTEXT weirdness

[Jan Nieuwenhuizen]

Marius Vollmer writes:

>>>   Makefile.am:26: AM_GNU_GETTEXT used but `po' not in SUBDIRS
>>
>> None of this happens here, what version of automake do you use?
>
> I have just upgraded to 1.9, with identical results.

Strange.  Can you double check you're using 1.9, and that aclocal.m4
is replaced, see, eg

http://sources.redhat.com/ml/automake-prs/2003-q1/msg00022.html

> I have a hard time convincing myself now that gettext support should
> be in the core, when I have, for example, not accepted SCTP.  Hmm.

I'm sure we'll get this fixed, don't worry.

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: AM_GNU_GETTEXT weirdness

[Kevin Ryde]

Marius Vollmer <mvo@zagadka.de> writes:
>
> inclusion
> of po/Makefile.in in _all_ AC_CONFIG_FILES statements in configure.in.

That's probably a bug :).

> Do we need po/?

I suppose only if guile's own messages are to be localized.

>     make[2]: Entering directory `/home/mvo/work/guile/guile-core/po'
>     make[2]: *** No rule to make target `all'.  Stop.

Try re-running configure (I think ... maybe).


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: AM_GNU_GETTEXT weirdness

[Bruno Haible]

Marius Vollmer wrote:
> >> running ./autogen.sh now runs gettextize

autoreconf shouldn't run gettextize. This was fixed in autoconf-2.57.

> >> and that causes some
> >> 'useless' things to happen, like the creation of po/

If you don't want a po/ directory, just don't run gettextize, and instead
do the steps (explained in the GNU gettext manual, chapter
"The Maintainer's View") manually.

> >> and the inclusion
> >> of po/Makefile.in in _all_ AC_CONFIG_FILES statements in configure.in.

This is a bug in gettextize that is fixed in the current gettext CVS
(not yet released; sorry).

> >>   Makefile.am:26: AM_GNU_GETTEXT used but `po' not in SUBDIRS

This is fixed in automake 1.8 and newer.

Jan Nieuwenhuizen wrote:

> > I have no clues whatsoever about what the developers of auto* have in
> > mind.  You'll have to ask Bruno about the AM_GNU_GETTEXT/libintl stuff.
> > What I had initially, was
> >
> >     dnl i18n tests
> >     AC_CHECK_HEADERS([libintl.h])
> >     AC_CHECK_FUNCS(gettext)
> >     if test $ac_cv_func_gettext = no; then
> >        AC_CHECK_LIB(intl, gettext)
> >     fi
> >     AC_CHECK_FUNCS([bindtextdomain textdomain])
> >
> > maybe something like that is better?
>
> Bruno, what is your view?

That autoconf test fails to detect an existing GNU libintl on _all_ platforms.
(Moreover it would pretend to have found gettext on Solaris without
GNU libintl, which would lead to linker errors later.)
Thus it works only on glibc systems, where no libintl is needed.

That's why I recommend the AM_GNU_GETTEXT macro.

> I have a hard time convincing myself now that gettext support should
> be in the core, when I have, for example, not accepted SCTP.  Hmm.

You have to estimate the importance of internationalization.

For illustration: In a new Linux magazine special issue about PHP 5, there
were about 6 or 7 introductory articles about this language and environment.
One of them was about how to use gettext from within PHP.

Bruno



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: AM_GNU_GETTEXT weirdness

[Marius Vollmer]

Bruno Haible <bruno@clisp.org> writes:

> Marius Vollmer wrote:
>> >> running ./autogen.sh now runs gettextize
>
> autoreconf shouldn't run gettextize. This was fixed in autoconf-2.57.

Ahh, OK.  I think I have it sorted out now, and have reverted our
configure.in to use AM_GNU_GETTEXT.  Hacking on guile-core from CVS
will now require GNU gettext, but that is OK.

> Jan Nieuwenhuizen wrote:
>
>> > I have no clues whatsoever about what the developers of auto* have in
>> > mind.  You'll have to ask Bruno about the AM_GNU_GETTEXT/libintl stuff.
>> > What I had initially, was
>> >
>> >     dnl i18n tests
>> >     AC_CHECK_HEADERS([libintl.h])
>> >     AC_CHECK_FUNCS(gettext)
>> >     if test $ac_cv_func_gettext = no; then
>> >        AC_CHECK_LIB(intl, gettext)
>> >     fi
>> >     AC_CHECK_FUNCS([bindtextdomain textdomain])
>> >
>> > maybe something like that is better?
>>
>> Bruno, what is your view?
>
> That autoconf test fails to detect an existing GNU libintl on _all_
> platforms.

In other words, it is buggy, right?

>> I have a hard time convincing myself now that gettext support should
>> be in the core, when I have, for example, not accepted SCTP.  Hmm.
>
> You have to estimate the importance of internationalization.

Yep, and also the importance of using the platform's gettext for it.
There is at least one gettext implementation in Scheme and maybe we
could just ship that...


In any case, with up-to-date-enough tools, everything seems to work
fine right now.  Thanks!


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: AM_GNU_GETTEXT weirdness

[Bruno Haible]

Marius Vollmer wrote:
> There is at least one gettext implementation in Scheme and maybe we
> could just ship that...

There's nothing wrong with emulating the C-written libintl library in a
higher-level language, in principle. Python, GNU Smalltalk, and OCaml,
for example, do this. They wrote all the necessary infrastructure
(character set converters - iconv() equivalent, and the code for parsing
and managing .mo files in memory) from scratch in their high-level language.
It's a choice of "slim vs. thick".

When libintl added extra features for Farsi and Arabic, you get them for
free by using libintl. With the emulation approach, you need to emulate
this as well, or you cannot use .mo files that make use of these features.
It's a choice of "reuse vs. reimplement".

Bruno



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: AM_GNU_GETTEXT weirdness

[Marius Vollmer]

Bruno Haible <bruno@clisp.org> writes:

> Marius Vollmer wrote:
>> There is at least one gettext implementation in Scheme and maybe we
>> could just ship that...
>
> [...]
> When libintl added extra features for Farsi and Arabic, you get them for
> free by using libintl. With the emulation approach, you need to emulate
> this as well, or you cannot use .mo files that make use of these features.
> It's a choice of "reuse vs. reimplement".

Yes.  I don't know much about i18n in general or gettext in
particular, and thus I have no real opinion on how complicated i18n is
and how much of that is covered by gettext.  In general, I'm a huge
fan of factoring out stuff: we had our own bignum arithmetic, but now
we use GNU mp for it.

Not using gettext only because we can't get it integrated into the
configure cruft of Guile seems silly, in any case.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel