Many GNOME packages and also other graphical packages are making use of intltool for their i18n, as this in addition to gettext helpers takes care of internationalization of many other things - including .desktop files, gconf schemas, and so on. It also honors LINGUAS for many of these and doesn't include translations to unlisted languages in the things it handles (e.g, your desktop files won't be bloated by dozens of languages translations making it bigger and slower than necessary). Intltool has an intltoolize command, alike to gettextize - it generates a po/Makefile.in.in and such things. These depend on the output of aclocal/automake and if these are re-run (e.g, by eautoreconf) then intltoolize has to be reran as well to ensure there aren't now missing @..@ type variables referenced or things missing in the po/Makefile.in.in file - see bug 199595 for a tracker tracking many breakages coming from intltoolize rerun missing after eautoreconf. Please consider adding intltoolize --force || die "intltoolize failed" in the end of eautoreconf if a) The package is using intltool, which is the case if the packages configure.in or configure.ac contains a call to IT_PROG_INTLTOOL b) the intltoolize binary exists and is executable This is blocking the addition of intltool-0.37.0 to the tree, which in turn might block GNOME-2.22. Alternative is to sanitize the tree to always call intltoolize after eautoreconf, but that seems too tedious compared to just calling it inside eautoreconf if appropriate - it HAS to be called anyhow after automake and co.
Apparently it's about mismatch between aclocal.m4 and Makefile.in.in instead.. Information and reasoning from upstream, discussed long ago - slightly edited IRC log: <leio> we have everything released with intltool-0.35.x fail build if the intltool installed on the system is 0.36.2 <dobey> you're probably running autoreconf, and not intltoolize <dobey> so you are mismatching the m4 and intltool scripts and Makefile.in.in <leio> yup, @INTLTOOL_MERGE comes up in the error message <dobey> because packages that use intltool, include the intltool scripts in their tarballs currently <dobey> yes you need to re-run intltoolize if you're going to do autoreconf <dobey> autoreconf has no knowledge of intltool <leio> hmm, I suppose intltoolize -f was supposed to come after autoreconf ;) <leio> and I don't believe we are using autoreconf anyway. We have our own eautoreconf <leio> that runs aclocal, automake, autoconf and a couple other things. But yes, that seems to be the problem <dobey> well whatever. the problem is you need to run intltoolize :) <leio> with --force ? <dobey> -f -c probably <leio> hmm, up to now lack of -c hasn't been a problem for some reason <dobey> oh maybe it unlinks first then <leio> what's the best way to find out if a package is using intltoolize? To have the best way to improve our eautoreconf to automatically intltoolize -f, but only on those packages that do use intltool <dobey> grep "^(IT|AC)_PROG_INTLTOOL" configure.{in,ac} <dobey> see gnome-autogen.sh from gnome-common or a more comprehensive check ... <dobey> i was hoping to get a few more patches in, and then making a final 0.36.x release <dobey> because i really want to get it out, and start doing the work on 0.40, to get rid of the need to have intltool included in tarballs .... <leio> would it be a good idea to try to push intltoolize into our eautoreconf? <dobey> yes <leio> with intltoolized project detection <leio> I mean in relation to the planned 0.40 work with not needing tarballs to carry the files <dobey> if intltoolize is what copies the Makefile.in.in over, then yes, it will still need to be run <leio> one problem is that maintainer are stuck at ancient versions often <leio> well, I don't know if it will be, but I suppose nothing else can be ;p <dobey> yeah, i'm not sure <leio> so with 0.40 it's not sure if it'll be necessary or not? <dobey> i'm not 100% certain right now, no <leio> I mean, if I go push that into eautoreconf, then later backing it out for 0.40 cases is not so good <dobey> the Makefile.in.in copying is the big thing <dobey> well <dobey> you won't have to back it out <leio> it'll be pretty much a no-op then? <dobey> the script will be around for a while no matter what, for compatibility reasons <dobey> if it just does nothing, it will just be #!/bin/true <dobey> so that it won't break stuff :)
Created attachment 144521 [details] gnome-autogen.sh from gnome-common-2.20.0 for reference here's the autogen from gnome-common for reference. case-insensitive search for intltool for relevant parts, especially around $INTLTOOLIZE
I'm retracting my request for now. It seems upgrade path is more or less fine, and upstream might remove this kind of Makefile inconsistency possibility in a future 0.40 release, so there's time to think about it more depending on what way upstream goes.
*** Bug 327673 has been marked as a duplicate of this bug. ***
this ended up getting fast tracked after merging autopoint support http://sources.gentoo.org/eclass/autotools.eclass?r1=1.139&r2=1.140
