Re: [libvirt] [PATCH] build: Fix version of gettext macros
Eric Blake wrote:
[adding bug-gnulib]
On 04/24/2012 06:22 AM, Eric Blake wrote:
> On 04/24/2012 03:50 AM, Peter Krempa wrote:
>> Commit c9cd419caba9effa11ca53e8696e5f6a4b424d60 added copying of the
>> makefile for translation files from gnulib. The makefile from gnulib is
>> of version 0.18 but the build configuration cretes macros from version
>> 0.17 which breaks the build with message:
>>
>> *** error: gettext infrastructure mismatch: using a Makefile.in.in from
>> gettext version 0.18 but the autoconf macros are from gettext version
>> 0.17
>> ---
>> bootstrap.conf | 2 +-
>> configure.ac | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> NACK. RHEL 5 still uses gettext 0.17, and this breaks the build there.
Not just RHEL 5, but RHEL 6.2 as well.
>
> We need to fix gnulib to not force us to use gettext 0.18. I'll look
> into this.
Here's what I'm playing with now; so far, it appears to make life happy
for libvirt with its intentional AM_GNU_GETTEXT_VERSION([0.17]). Jim,
does this look like a reasonable approach? Any suggestions before we
make it official in gnulib?
Hi Eric,
That change is effectively disabling the build-time check that ensures
Makefile.in.in and gettext.am versions are in sync. That version
comparison is definitely the problem[*], but I haven't tried using
an older gettext.m4 with newer Makefile.in.in like you propose to do.
I have just inspected gettext's v0.17..HEAD Makefile.in.in diffs, and
don't see a problem in this particular case. I think libvirt builds
will work fine with those two files mismatched. However, I remember
(too well: http://bugzilla.redhat.com/523713) that using some older-still
version of gettext.m4 caused a hard-to-diagnose failure when used with
newer Makefile.in.in.
Since it could cause trouble with other (and perhaps future)
combinations of version numbers, any such disabling should remain
libvirt-specific. Possible alternative: a very specific transformation
that would disable the test only in the precise 0.17-vs-0.18 case, once
you have confirmed it is ok.
An alternative that I've always advocated, when developing on
systems with build tools that are out of date, is to build and
install private copies of the latest tools. This script
automates that task:
http://people.redhat.com/meyering/autotools-install
See its --help output for a recommended way to invoke it.
[*] Rather than comparing gettext version numbers, it could be
comparing some version number associated with the API that
covers those two files. I suppose that this API version number
would change less frequently than the gettext package version number.
diff --git i/bootstrap w/bootstrap
index 5aa73cc..1cacd03 100755
--- i/bootstrap
+++ w/bootstrap
@@ -1,6 +1,6 @@
#! /bin/sh
# Print a version string.
-scriptversion=2012-04-19.22; # UTC
+scriptversion=2012-04-25.04; # UTC
# Bootstrap this package from checked-out sources.
@@ -873,7 +873,14 @@ if test $with_gettext = yes; then
}
' po/Makevars.template >po/Makevars || exit 1
- cat $GNULIB_SRCDIR/build-aux/po/Makefile.in.in > po/Makefile.in.in ||
exit 1
+ gettext_sed='s/^[ ]*AM_GNU_GETTEXT_VERSION(\[*\([^]]*\)\]*).*/\1/p'
+ gettext_version=$(sed -n "$gettext_sed" configure.ac)
+ if test -n "$gettext_version"; then
+ sed "s/\(Origin:.*-\|MACRO_VERSION =
\)0\.[0-9][0-9]/\1$gettext_version/" \
+ $GNULIB_SRCDIR/build-aux/po/Makefile.in.in > po/Makefile.in.in ||
exit 1
+ else
+ cp $GNULIB_SRCDIR/build-aux/po/Makefile.in.in po/Makefile.in.in ||
exit 1
+ fi
if test -d runtime-po; then
# Similarly for runtime-po/Makevars, but not quite the same.