GNOME Bugzilla – Bug 705365
aclocal runs before intltool macros are copied
Last modified: 2013-08-27 13:59:44 UTC
Created attachment 250727 [details] [review] Patch to intltoolize before aclocal is run When running gnome-autogen.sh from master, aclocal is run by autoreconf before intltool.m4 is copied into the macro dir. This causes configure files which use IT_PROG_INTLTOOL to fail, as the macro is not included in aclocal.m4. Reordering intltoolize and autoreconf solves this problem without introducing any other apparent issues. A patch is attached, and I can commit it if it is approved.
It appears this does cause a problem: if autopoint is run (by autoreconf) after intltoolize, it replaces po/Makefile.in.in and configure complains that said file isn't created by intltoolize. This creates a conflict, though. Either we need to run autoreconf, intltoolize, then aclocal, or intltoolize, autoreconf, intltoolize.
Review of attachment 250727 [details] [review]: I think that the best way to solve this is to set AUTOPOINT to "intltoolize…" if the intltool M4 macro is found in configure.ac. The bug was triggered (I guess) by a configure.ac which uses AM_GNU_GETTEXT and IT_PROG_INTLTOOL, which is unsupported by intltool: https://bugs.launchpad.net/intltool/+bug/654918
Hello Seán de Búrca, I tried the modules you seems to have problems with (gnome-bluethoot and gnome-online-accounts) and seems to build fine here (also the IT_PROG_INTLTOOL macro is included in aclocal.m4) Could you be a little more specific about how to reproduce the bug? Thanks!
Comment on attachment 250727 [details] [review] Patch to intltoolize before aclocal is run Rejected as this makes inttltool to complain about po/Makefile.in.in
I encountered this bug while running a clean jhbuild build on Fedora 19. In each case, a clean tree from git would cause aclocal to be run before intltoolize, meaning there was no intltool.m4 in the macro dir when aclocal was run and causing configure to fail due to missing IT_PROG_INTLTOOL. Rerunning autogen.sh after configure failed the first time would then include the contents of intltool.m4 in aclocal.m4, since the macro file was present when aclocal was run. This happened consistently across packages using gnome-autogen.sh in the jhbuild tree until patched.
I tried changing AUTOPOINT, but this results in config.rpath and ABOUT-NLS not being copied, which will cause automake to fail. Either we can file bugs against packages with both IT_PROG_INTLTOOL and AM_GNU_GETTEXT, whose consequences I'm not certain of, or we could set AUTOPOINT to not --force, meaning it won't replace po/Makefile.in.in.
Using both IT_PROG_INTLTOOL and AM_GNU_GETTEXT is a bug, so please file bugs against packages which do that. The intltool documentation now says that only IT_PROG_INTLTOOL should be used: https://code.launchpad.net/~robert-ancell/intltool/remove-am-gnu-gettext/+merge/114274
In that case, the behavior of the initial patch should be correct. I'll start filing bugs against packages where applicable.
Review of attachment 250727 [details] [review]: I was able to reproduce the bug with a clean jhbuild install and build tree. gnome-online-accounts was the first package affected. Applying the patch corrected the issue. As per David King's comments, I have filed bugs against all packages in the gnome-core moduleset in jhbuild which use both IT_PROG_INTLTOOL and AM_GNU_GETTEXT and will be filing bugs against any in gnome-apps-3.10 that have the same problem. After patching the affected packages, I experienced no build failures and the packages in question appear to be correctly localized. The patch as currently attached should now be correct.
Review of attachment 250727 [details] [review]: Tested and seems fine. When you commit, please make sure to add a link to this bug. Thanks!
Review of attachment 250727 [details] [review]: https://git.gnome.org/browse/gnome-common/commit/?id=ac800833454ab6d38afb288773079b8ad1d5503f