Makefile.in.in doesn't pass down XGETTEXT and MSGFMT

[Bernd Jendrissek]

I see this in pcb's autogen.sh:

+# both intltoolize and autopoint create a po/Makefile.in.in, this can't be good...
+# but intltoolize seems to have some bugs in it. In particular, XGETTEXT and MSGFMT
+# are set in the Makefile but not passed down when calling MSGMERGE or GENPOT.
+# This defeats specifying the path to xgettext and msgfmt.

(See http://git.gpleda.org/?p=pcb.git;a=commitdiff;h=858765b213b80c88f52abe597805f3c7368f53db for the full diff.)

I'm only reporting this because I found this while checking if it was safe to use autoreconf instead of yet another autogen.sh, not because I'm personally affected by this purported problem. Presumably it affects people with weird $PATH / other environment setups.

[Данило Шеган (danilo)]

intltool Makefile.in.in is based on gettext one, but it always lags behind. We should probably get it up to date and figure out a way to not worry about this in the future.

Using autopoint and intltoolize in one project is bad practice, so that bit (where they both produce Makefile.in.in) is not a bug.

[dobey (dobey)]

Using both autopoint and intltool is fine. You just need to make sure they are called in the correct order. The same issues exist when using glib-gettextize and intltool. It just happens that gnome-common always calls them in the correct order. And that order is that intltoolize must be called after autopoint, gettextize, or glib-gettextize.

The other issue is that autoreconf knows nothing of intltool. You must call intltoolize afterward if you are going to use it. If autoreconf knew about intltoolize, there wouldn't be any issue.