Makefile uses non-portable features

[Peter Selinger]

When internationalizing a package with intltool, the created po/Makefile contains non-portable code that breaks, for example, with the default "make" of FreeBSD.

Specifically, lines such as

CATALOGS=$(shell LINGUAS="$(USE_LINGUAS)"; for lang in $$LINGUAS; do printf "$$lang.gmo "; done)

are not understood by FreeBSD's "make", resulting in the error message:

Error expanding embedded variable.

It seems that the specific thing disallowed here is the use of "$$" inside of a $(shell ...) statement.

As a result, packages that use intltool cannot be build on FreeBSD. See e.g., https://sourceforge.net/p/ccrypt/bugs/17/

[Peter Selinger (selinger)]

It seems that the bug was introduced in intltool-0.35.0, probably here:

2006-04-11 Rodney Dawes <email address hidden>

        * Makefile.in.in: Dump localedir, gnuclocaledir, and gettextsrcdir
        variables as we no longer need them
        Add DATADIRNAME substitution handling and define itlocaledir with it
        Dump GMOFILES as it is not used in here
        Add in a variable to deal with old ALL_LINGUAS
        Set up PO_LINGUAS to get the locales from the LINGUAS file
        Set up POFILES to be generated from one of PO_LINGUAS or ALL_LINGUAS
        Dump CATOBJEXT as we no longer need it in here
        Set up CATALOGS to be genereated from one of PO_LINGUAS or ALL_LINGUAS
        Replace usage of CATALOGS to decipher the locale from, with straight
        usage of either PO_LINGUAS or ALL_LINGUAS to get the locale names

[dobey (dobey)]

GNU make is required by intltool here. I don't think ther eis any reasonable solution to have this portion of code in the Makefile be portable across different make programs. So I'm setting this to won't fix.

[Peter Selinger (selinger)]

Hi Rodney,

thanks for your comment. I understand that GNU make is a requirement to *run* intltool, but should it also be a requirement for building any intltoolized packages?

The point is that intltool is run by package maintainers when preparing packages for internationalization, making source distributions, and all that. These are maintainer tasks, so it is okay to require all kinds of non-portable tools for that.

But on the other hand, shouldn't the resulting packages then be able to be compiled and installed anywhere? It has always been my assumption that that was one of the central goals of the autoconf/automake/intltool suite of tools. I am talking about the ./configure; make; make install part of the build process of some package that uses internationalization. These are tasks for the package installer (typically end user).

The problem with this bug is that it does not just affect the person running intltoolize or similar. It affects the actual person installing the resulting package. I still think that this is a bug, because the task that breaks the Makefile has something to do with detecting which translations are available. That is a maintainer issue that should be resolved at distribution time, not at build time.

If the packages prepared with intltool are no longer portable, that would be a shame. Please consider fixing this!

Thanks, -- Peter