From: Marius Vollmer <mvo@zagadka.de>
Cc: guile-devel@gnu.org
Subject: Re: AM_GNU_GETTEXT weirdness
Date: Sat, 25 Sep 2004 01:36:54 +0200 [thread overview]
Message-ID: <874qln8cix.fsf@zagadka.ping.de> (raw)
In-Reply-To: <87vfe4xhis.fsf@peder.flower> (Jan Nieuwenhuizen's message of "Fri, 24 Sep 2004 09:17:31 +0200")
[ 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
next prev parent reply other threads:[~2004-09-24 23:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-24 2:40 AM_GNU_GETTEXT weirdness Marius Vollmer
2004-09-24 7:17 ` Jan Nieuwenhuizen
2004-09-24 23:36 ` Marius Vollmer [this message]
2004-09-25 7:13 ` Jan Nieuwenhuizen
2004-09-28 16:07 ` Bruno Haible
2004-09-28 19:03 ` Marius Vollmer
2004-09-28 19:55 ` Bruno Haible
2004-09-28 21:13 ` Marius Vollmer
2004-09-25 21:30 ` Kevin Ryde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874qln8cix.fsf@zagadka.ping.de \
--to=mvo@zagadka.de \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).