Out of curiousity what are those downstream projects? I'm also curious why they need to run autoreconf.
So far, I know of MacPorts (bug #1407009):
<quote> Due to no fault with Inkscape at all, MacPorts' support for multiple perl versions requires that ports that depend on intltool be reconfigured with a custom version of intltool.m4. </quote>
...and Debian + derivatives. In this case, I don't see why it is necessary (in fact I suggested that to the Debian maintainer!).
What were the changes in the internationalization config?
This change in configure.ac [1], in which we updated some ancient config macros. The new set looks like this...
IT_PROG_INTLTOOL([0.40.0]) AM_GNU_GETTEXT_VERSION([0.17]) AM_GNU_GETTEXT([external])
The problem is this:
1. If you run autoreconf (not autogen.sh) it sees that gettext is being used, and generates the po/Makefile.in.in file using autopoint. 2. Now, when you run the configure script, the IT_PROG_INTLTOOL macro inspects the po/Makefile.in.in file, and sees that it was created by autopoint, NOT by intltoolize. The configure script then fails.
We get around this in autogen, by a slightly horrible hack, in which we override the AUTOPOINT variable, so that intltoolize is run when autoreconf sees the gettext macros in configure.ac.
The correct way of doing it is documented in the intltool manual [2]:
1. Only use the IT_PROG_INTLTOOL macro in configure.ac (not the gettext ones) 2. Manually call intltoolize in autogen.sh before running autoreconf (autoreconf won't do it automatically)
I am not a translation guru...
Neither am I, so I'd really appreciate some testing of this fix, or some advice before I commit!
Best wishes,
Alex
[1] http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12150 [2] https://code.launchpad.net/~robert-ancell/intltool/remove-am-gnu-gettext/+me...
On 11 February 2015 at 19:24, Bryce Harrington <bryce@...961...> wrote:
On Wed, Feb 11, 2015 at 01:11:31PM +0000, Alex Valavanis wrote:
Hi All,
Please could someone take a look at the issue reported in bug #1407009 [1] and bug #1418943 [2]?
In short...
A lot of downstream projects like to regenerate the configuration files by running "autoreconf". Builds fail in 0.91.0 because of changes in the internationalization config.
To reproduce:
autoreconf -fi ./configure
# Config dies with a message about po/Makefile.in.in not being created by intltoolize.
To fix this, we need to distribute autogen.sh, and preferably update the macros used in configure.ac. Is there any reason not to do this, and backport to 0.91.1?
That's a logical fix for producing 0.91.1.
I'm a bit busy with other projects right now, but I will make time to produce this build once the fixes are in. Would you mind putting out a call for patches for 0.91.1, if there are other fixes to go in? There were some post-release Windows bugs iirc.
However I wonder if shipping autogen.sh is the best solution, or if that's just papering over the real problem?
What were the changes in the internationalization config? I should mention there's a step in the release process where it tells me to regenerate the .pot file, which I have generally skipped on the assumption that the translators are keeping it up to date. Possibly I need to run that as a final step? I need some guidance here since I am not a translation guru...
If there's no feedback, I'll press ahead in the next day or so, since it's holding up the distribution of Inkscape 0.91 to some major downstream projects.
Out of curiousity what are those downstream projects? I'm also curious why they need to run autoreconf.
Thanks, Bryce