GNOME Bugzilla – Bug 577133
intltool-0.40.6 does not work properly
Last modified: 2009-05-12 11:21:39 UTC
On gentoo, we sometimes re-generate autotools of a package for some reason and need to call intltoolize to make sure everything builds and installs fine. This far things went just fine until intltool-0.40.6 got introduced to the tree. I'll attach in a moment the diff between a build with intltool-0.40.5 and 0.40.6 to show what's wrong.
Created attachment 131600 [details] [review] nautilus-open-terminal-build.diff you can see how it's not doing what it is supposed too. If we are doing things wrong, please advise of the best method to use intltool after updating autotools of a package. Thanks in advance.
What exactly is the problem? You say it doesn't work, but I am not sure what you are expecting, and I don't see anything in your attachment that points to an obvious problem.
This part of the diff: ---- /usr/share/locale/ ---- /usr/share/locale/fr/ ---- /usr/share/locale/fr/LC_MESSAGES/ ->>> /usr/share/locale/fr/LC_MESSAGES/nautilus-open-terminal.mo no locales get installed at all with 0.40.6 while the exact same steps to build the packages with 0.40.5 lead to installation of locales. In both cases, my LINGUAS env variable was set to fr.
The problem in question is in the way intltool generates Makefile.in: Gentoo patches some Makefiles and therefore needs to regenerate Makefile.in for some projects, like nautilus-open-terminal. This is done by after patching running intltoolize --force --copy --automake eautoreconf Where eautoreconf is a script more or less running autoreconf. When shifting from intltool-0.40.5 to intltool-0.40.6 the generated output in Makefile{,.in,in.in} does change in the following way (the directory postfixed with ".old" is with intltool-0.40.5, and the other is with intltool 0.40.6): --- nautilus-open-terminal-0.9-r2.old/work/nautilus-open-terminal-0.9/po/Makefile.in 2009-03-30 10:47:29.106234403 +0200 +++ nautilus-open-terminal-0.9-r2/work/nautilus-open-terminal-0.9/po/Makefile.in 2009-03-30 10:56:18.462233566 +0200 @@ -56,7 +56,7 @@ PO_LINGUAS=$(shell if test -r $(srcdir)/LINGUAS; then grep -v "^\#" $(srcdir)/LINGUAS; else echo "$(ALL_LINGUAS)"; fi) -USER_LINGUAS=$(shell if test -n "$(LINGUAS)"; then LLINGUAS="$(LINGUAS)"; ALINGUAS="$(ALL_LINGUAS)"; for lang in $$LLINGUAS; do if test -n "`grep ^$$lang$$ $(srcdir)/LINGUAS 2>/dev/null`" -o -n "`echo $$ALINGUAS|tr ' ' '\n'|grep ^$$lang$$`"; then printf "$$lang "; fi; done; fi) +USER_LINGUAS=$(shell if test -n "$(LINGUAS)"; then LLINGUAS="$(LINGUAS)"; ALINGUAS="$(ALL_LINGUAS)"; for lang in $$LLINGUAS; do if test -n "`grep '^$$lang$$' $(srcdir)/LINGUAS 2>/dev/null`" -o -n "`echo $$ALINGUAS|tr ' ' '\n'|grep '^$$lang$$'`"; then printf "$$lang "; fi; done; fi) Mind the ' around ^$$lang$$. With them USER_LINGUAS becomes empty (and the Makefile fails to generate any ".gmo"s), without them USER_LINGUAS becomes the same as LINGUAS (and the Makefile generates a .gmo for each entry in LINGUAS that has a .po). Also mind that this is if LINGUAS is set. If LINGUAS is unset, ALL_LINGUAS are used instead and this codepath is never used, thus all .gmo's are built. I think what Gilles wants to know is if this is a expected behaviour and if the missing .gmo's is becouse of the autotools in nautilus-open-terminal, the way Gentoo runs intltoolize or a bug in intltool.
Just to be un-helpful: as all of you probably already know, this particular change (according to svn log), was done to fix bug 559528. Anybody willing to test, if the original idea (escaping) would work ?
OK, now that I read make's info page, I understood, why that "fix" broke things: it simply caused $lang to not be expanded.
This is fixed in trunk in bzr (http://code.launchpad.net/intltool) now.
In the original report it sounded like you did not like using \ so why use it instead of "? As the ` takes precedence over " it is no problem to have "`command "$var"`"?
*** Bug 582264 has been marked as a duplicate of this bug. ***