Re: Bug#365727: update-po target in Makefile.in.in fails because of a small bug (fwd)

[Daniel Leidert]

Am Mittwoch, den 14.06.2006, 22:44 +0200 schrieb Bruno Haible: 
> Daniel Leidert wrote:
> > > Or where else did your po/Makefile.in.in
> > > come from?
> > 
> > May I use the next paragraph to answer your question?
> > 
> > > > for a package, where intltool is only used to translate a XML file. So I
> >                          ^^^^^^^^ (0.34.2)
> 
> The problem is fixed in intltool-0.35 that was released three weeks
> ago.
> 
> > 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? 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(!). The only difference between
these INTLSYMBOL values is (from my point of reading), the existence of
the intl sub-directory in the source directory. I still consider this a
bug in gettext. Of course, intltool removed CATOBJEXT from it's
Makefile.in.in template in version 0.35.0, but that is not the question.

> > > > USE_NLS=no
> > > 
> > > This conflicts with the GNU gettext macros. They define USE_NLS already,
> > > to a value that depends whether --disable-nls has been specified.
> > 
> > I know. This is a (probably dirty) workaround to avoid the installation
> > of the catalogs (I don't need them, they are just used to create the
> > final XML file).
> 
> If you don't need the catalogs, you can either pass the option
> --disable-nls when you configure the package. (It's common to use
> some configure options even for one's own package, since the defaults
> are made for the majority of people. I routinely configure my packages
> with   CPPFLAGS="-Wall" CFLAGS="-g" --disable-shared   and similar.)
> 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).

> (At least with GNU gettext
> po/Makefile.in.in - I don't know about intltool.)

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.
Situation has changed with latest intltool release. But that is probably
also the result of the discussion I started months(!) ago on intltools
mailing list
(http://lists.freedesktop.org/archives/intltool/2006-February/001320.html). The 
point of discussion was the missing CATOBJEXT value when using 
AM_GNU_GETTEXT([external]) (and only external) and not the workarounds I had to 
use because of limitations(design decisions. And this bug-report was not 
written yesterday. It was written at the beginning of May.

Regards, Daniel