bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug#365727: update-po target in Makefile.in.in fails because of a sm


From: Bruno Haible
Subject: Re: Bug#365727: update-po target in Makefile.in.in fails because of a small bug (fwd)
Date: Tue, 20 Jun 2006 14:01:15 +0200
User-agent: KMail/1.9.1

Daniel Leidert wrote:
> > > The issue then is, that in the special case I describe, CATOBJEXT, which
> > > is necessary for intltools po/Makefile.in.in is not shipped.
> > 
> > ok. intltool's Makefile.in.in needs a macro that gettext.m4 doesn't
> > define - a bug in the intltool package.
> 
> AM_GNU_GETTEXT([external]) does not deliver CATOBJEXT. Why this is a bug
> in intltool?

Because CATOBJEXT is not mentioned in the gettext documentation.
AM_GNU_GETTEXT([external]) is documented to work with the Makefile.in.in
that gettextize installs. If intltool uses a macro CATOBJEXT that is
not documented, it's dangerous coding as long as it works, and a bug
when it stops working.

> gettext.m4 states 'INTLSYMBOL should be 'external' for
> packages with no intl directory,'. I cannot read from this, why
> CATOBJEXT is not defined in this case. In both other cases (no-libtool,
> use-libtool), CATOBJEXT gets/has a value(!).

Whether CATOBJEXT is set in some cases or not, is irrelevant. The only
thing that matters is the documentation. It does not and never did mention
CATOBJEXT, therefore you cannot count on CATOBJEXT being set.

> > Or you set the LINGUAS environment variable to empty; this will avoid
> > installing catalogs from your builds. (At least with GNU gettext
> > po/Makefile.in.in - I don't know about intltool.)
> 
> It was not possible to use --disable-nls for this purpose at the time I
> wrote the bug-report. And the suggestion to set ALL_LINGUAS to an empty
> value is also not an alternative
> (http://lists.freedesktop.org/archives/intltool/2006-February/001325.html).

Congratulations that you already explored that alternative!

> But I know. So maybe you can now stop trying to teach me about things I
> already examined and which are not the object of this bug report.

Cool, that you already examined that, and incited improvements to intltool!

Please don't insult those who try to help you: How could I know what you
already reported or suggested on various mailing lists that I don't read? All
that I saw was this particular report. Your aggressive tone is unjustified.

Anyway, thank you for helping that GNU gettext and intltools work better
together!

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]