m4: --disable-nls doesn't prevent intltool checks

[Arun Raghavan]

IT_PROG_INTLTOOL checks for the existence of intltool even if --disable-nls is provided. IMO this is incorrect.

[Hib Eris (hiberis)]

Packages that use intltool for example to internationalize *.desktop files always build-depend on intltools to create the *.desktop file from a *.desktop.in file. Thus it is impossible to build such a package without intltool.

 The option --disable-nls might suggest that you can disable internationalization, but you cannot disable the use of intltools and thus this option should NOT disable the checks for intltool.

IMO, the option --disable-nls is confusing and should not be added to the configure options by using IT_PROG_INTLTOOL.
(that means remove AM_NLS from intltool.m4 and replace it with just:

if -z $USE_NLS; then USE_NLS=yes;fi
AC_SUBST(USE_NLS)

[Hib Eris (hiberis)]

I have rewritten intltool.m4 to allow --disable-nls:

lp:~hiberis/intltool/bug-904647

[Hib Eris (hiberis)]

I have updated my branch to current trunk

[Mr Anonimus (altj2)]

this bug is very annoying. i do not need translations and so i --disable-nls in all autoconf packages,
but those using libintl need a huge amount of patches in order not to pull in dependencies on intltool, perl, and XML::Parser. (which are quite heavy build dependencies).
since i build a distro from source this happens all over a again. i already spend countless hours of
cpu time for testbuilds just for the otherwise not necessary perl dependency.

imo an easy way to solve the dilemma with the .desktop files is this:
if HAVE_INTLTOOL
   intltool-merge ... foo.desktop.in foo.desktop
else
   cat foo.desktop.in | sed 's,^_,,' > foo.desktop
fi

[Mr Anonimus (altj2)]

as a compromise, it would help a lot if intltool.m4 stops checking for perl and the XML::Parser module.

that way one could at least provide a minimal intltool replacement that just returns the english strings.

basically you want to check if intltool is installed and working, right ?

whether it uses perl and XML::Parser behind the back are implementation details, someday someone might rewrite intltool in C or in python or whatever, but it will take years until the change in intltool.m4 propagates into release tarballs.

so imo it'd be much cleaner if the .m4 file just checks whether the intltool-tools are installed, and assume them to be working.