The Gnulib module 'maintainer-makefile' has two bad effects on the packages
that import it. When GNU make is used (i.e. practically all GNU systems):
1) It executes the compilation of files (in lib/, src/, etc.) in the C locale.
Thus, even if the user who builds the program has a preferred language (other
than English) and GCC is built with enabled NLS, the 'maintainer-makefile'
module forces English diagnostics onto the user.
2) It executes the unit tests ("make check-recursive", invoked by "make check")
in the C locale. Thus, although most users nowadays execute programs in an
UTF-8 locale (namely, the one set by their distro or desktop environment),
the test suite only ever gets run in the C locale.
This significantly reduces the value of the test suite. For example, GNU m4
has a unit test for every built-in function, and m4 1.4.19 introduced a
regression in all locales which use a comma as decimal separator (this
includes French and German locales). THE TEST SUITE did not catch it when
run by the maintainer. It's only by building the package on DragonFly BSD
that I noticed the regression (more than a week after the release, since
obviously few GNU contributors use a non-GNU make).
The bad effects affect
* the developers who work from a git checkout + all users of the tarball
for packages that include GNUmakefile and maint.mk in their tarballs,
e.g. GNU findutils, GNU guile, GNU gzip, GNU libidn, GNU m4, GNU patch,
GNU poke.
* the developers who work from a git checkout only, for the other packages
that use this module, e.g. GNU emacs, GNU gettext.
In the second case, the testers of a pretest tarballs have a chance to discover
the test failures that were hidden from the maintainers. In the first case,
it's even worse, as only the use of non-GNU make can uncover the bugs.
The line that causes these bad effects is in maint.mk:
export LC_ALL = C
Probably this line made sense when maint.mk was still called Makefile.maint
and was independent. But since 2006 (or earlier) it is being included via
GNUmakefile.
Bruno
