intltool: Why has our intltool.m4 patch not been accepted by the intltool developers?

[ryandesign (Ryan Carsten Schmidt)]

In our intltool port we patch intltool.m4 to remove a bug (the fact that it searches for perl, which it does not need to do). Why do we have to carry this patch forward forever? Why can the developers of intltool not accept this patch into their software?

Several projects bundle intltool.m4; when they do, we then have to add the patch to those as well (see e.g. #60130). This becomes tedious.

[ctreleaven (Craig Treleaven)]

Symptom: A project using intltool will fail in the configure step with output similar to:

...
checking for perl... /opt/local/bin/perl
checking for perl >= 5.8.1... 5.28.3
checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool
Command failed:  cd "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_geany/geany/work/geany-1.38" && ./configure --prefix=/opt/local --disable-silent-rules --disable-vte --disable-html-docs --disable-pdf-docs --disable-api-docs --disable-gtkdoc-header 
Exit code: 2
Error: Failed to configure geany: consult /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_geany/geany/work/geany-1.38/config.log
Error: Failed to configure geany: configure failure: command execution failed
DEBUG: Error code: NONE

Workarounds: Until the initltool project applies the fix referenced above (they haven't in 9 years now), there are two possible workarounds:

1) Use autoreconf. The MacPorts version of intltool.m4 has been fixed and will produce a working configure script.

use_autoreconf        yes
autoreconf.args       --install --verbose --force

2) Patch the upstream-provided configure script to remove the offending check. For example, see ​https://github.com/macports/macports-ports/blob/master/xfce/libxfce4ui/files/remove-intltool-perl-hack.diff

The upstream bug report: ​https://bugs.launchpad.net/intltool/+bug/1197875

Hope this helps others.