[libvirt] [PATCH] build: Fix version of gettext macros
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(-) diff --git a/bootstrap.conf b/bootstrap.conf index c6620e5..56911e0 100644 --- a/bootstrap.conf +++ b/bootstrap.conf @@ -195,7 +195,7 @@ buildreq="\ autoconf 2.59 automake 1.9.6 autopoint - -gettext 0.17 +gettext 0.18 git 1.5.5 gzip - libtool - diff --git a/configure.ac b/configure.ac index 89fe818..5936d31 100644 --- a/configure.ac +++ b/configure.ac @@ -2300,7 +2300,7 @@ dnl compute the difference between save_CPPFLAGS and CPPFLAGS and append it dnl to INCLUDES in order to preserve changes made by gettext but in a place dnl that does not break the build save_CPPFLAGS="$CPPFLAGS" -AM_GNU_GETTEXT_VERSION([0.17]) +AM_GNU_GETTEXT_VERSION([0.18]) AM_GNU_GETTEXT([external]) GETTEXT_CPPFLAGS= if test "x$save_CPPFLAGS" != "x$CPPFLAGS"; then -- 1.7.3.4
On Tue, Apr 24, 2012 at 11:50:51AM +0200, 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(-)
diff --git a/bootstrap.conf b/bootstrap.conf index c6620e5..56911e0 100644 --- a/bootstrap.conf +++ b/bootstrap.conf @@ -195,7 +195,7 @@ buildreq="\ autoconf 2.59 automake 1.9.6 autopoint - -gettext 0.17 +gettext 0.18 git 1.5.5 gzip - libtool - diff --git a/configure.ac b/configure.ac index 89fe818..5936d31 100644 --- a/configure.ac +++ b/configure.ac @@ -2300,7 +2300,7 @@ dnl compute the difference between save_CPPFLAGS and CPPFLAGS and append it dnl to INCLUDES in order to preserve changes made by gettext but in a place dnl that does not break the build save_CPPFLAGS="$CPPFLAGS" -AM_GNU_GETTEXT_VERSION([0.17]) +AM_GNU_GETTEXT_VERSION([0.18]) AM_GNU_GETTEXT([external]) GETTEXT_CPPFLAGS= if test "x$save_CPPFLAGS" != "x$CPPFLAGS"; then
ACK, I thought I was going mad when I saw this even after doing a git clean Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 04/24/2012 11:57 AM, Daniel P. Berrange wrote:
On Tue, Apr 24, 2012 at 11:50:51AM +0200, 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 ---
ACK, I thought I was going mad when I saw this even after doing a git clean
Thanks; pushed. It was annoying not being able to build the HEAD. Peter
Daniel
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. We need to fix gnulib to not force us to use gettext 0.18. I'll look into this. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Tue, Apr 24, 2012 at 06:22:44AM -0600, 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.
We need to fix gnulib to not force us to use gettext 0.18. I'll look into this.
Can we just remote the change Peter mentiones above that cause this to break in the first place ? It doesn't seem right to me, to be using gnulib's makefile for the po/ dir, instead of the one our gettext actually desires. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 04/24/2012 06:52 AM, Daniel P. Berrange wrote:
On Tue, Apr 24, 2012 at 06:22:44AM -0600, 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.
We need to fix gnulib to not force us to use gettext 0.18. I'll look into this.
Can we just remote the change Peter mentiones above that cause this to break in the first place ? It doesn't seem right to me, to be using gnulib's makefile for the po/ dir, instead of the one our gettext actually desires.
Yep, I'm working on it, but it involves a change to upstream gnulib to make bootstrap not forcefully override our desired versions. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
[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? 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. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
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.
On Wed, Apr 25, 2012 at 03:04:05PM +0200, Jim Meyering wrote:
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.
Why is gnulib trying to force a particular po/Makefile.in.in version onto apps ? We declared what gettext we want to use, so we should just be using the Makefile.in.in that comes with that version, not any other version. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 04/25/2012 07:04 AM, Jim Meyering wrote:
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.
The 0.17/0.18 diff worked for me, but as you say...
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.
anyone trying to target older gettext than RHEL 5 may have issues, or Bruno may accidentally break things again in gettext 0.19.
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.
Another possible alternative: install the precise 0.17 Makefile.in.in via libvirt's gnulib-local, so that when gnulib-tool runs, we are back to bootstrap picking up the version that we know we want to use in libvirt.
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:
But then _every_ developer on the project must do the same setup on _every_ one of their development machines; and libvirt has enough developers spread over enough machines that this gets to be painful, when we can instead rely on a known stable version as provided by distros instead. Then again, gnulib's DEPENDENCIES file does state: * GNU gettext. + Always use the newest available gettext release, see <http://www.gnu.org/software/gnulib/manual/html_node/gettextize-and-autopoint.html>. + Recommended. Needed if you use modules that use internationalization (many do). + Homepage: http://www.gnu.org/software/gettext/ + Download: http://ftp.gnu.org/gnu/gettext/ ftp://ftp.gnu.org/gnu/gettext/ whereas for other tools, it is pretty lax (m4 1.4.5, autoconf 2.59, automake 1.9.6 - again, catering to RHEL 5). Can libvirt really be the only project that _doesn't_ want to use bleeding edge toolchain, and if so, is this evidence of a larger problem with gnulib's DEPENDENCIES regarding gettext?
- cat $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
Finally, even if I don't push this full patch to upstream gnulib, would it hurt if we changed this unusual cat into a more idiomatic cp, as I proposed here? -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Eric Blake wrote:
On 04/25/2012 07:04 AM, Jim Meyering wrote:
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.
The 0.17/0.18 diff worked for me, but as you say...
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.
anyone trying to target older gettext than RHEL 5 may have issues, or Bruno may accidentally break things again in gettext 0.19.
That is very unlikely. I was thinking of a deliberate change/fix that would render the mix of old and new parts invalid.
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.
Another possible alternative: install the precise 0.17 Makefile.in.in via libvirt's gnulib-local, so that when gnulib-tool runs, we are back to bootstrap picking up the version that we know we want to use in libvirt.
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:
But then _every_ developer on the project must do the same setup on _every_ one of their development machines; and libvirt has enough developers spread over enough machines that this gets to be painful, when we can instead rely on a known stable version as provided by distros instead.
Not *every*... on *every*... This would apply only to developer systems with outdated gettext.
Then again, gnulib's DEPENDENCIES file does state:
* GNU gettext. + Always use the newest available gettext release, see
<http://www.gnu.org/software/gnulib/manual/html_node/gettextize-and-autopoint.html>. + Recommended. Needed if you use modules that use internationalization (many do). + Homepage: http://www.gnu.org/software/gettext/ + Download: http://ftp.gnu.org/gnu/gettext/ ftp://ftp.gnu.org/gnu/gettext/
whereas for other tools, it is pretty lax (m4 1.4.5, autoconf 2.59, automake 1.9.6 - again, catering to RHEL 5). Can libvirt really be the only project that _doesn't_ want to use bleeding edge toolchain, and if so, is this evidence of a larger problem with gnulib's DEPENDENCIES regarding gettext? ...
- cat $GNULIB_SRCDIR/build-aux/po/Makefile.in.in > po/Makefile.in.in || + cp $GNULIB_SRCDIR/build-aux/po/Makefile.in.in po/Makefile.in.in ||
Finally, even if I don't push this full patch to upstream gnulib, would it hurt if we changed this unusual cat into a more idiomatic cp, as I proposed here?
You're welcome to make that isolated s/cat...>/cp .../ change. This isn't the same case I had to make for http://bugzilla.redhat.com/523713, but imho, the conclusion is the same: tools like gettext, autoconf, automake are special (they're not like libraries, and pay far more attention to portability and backwards compatibility than most other packages) and should be updated more frequently, even in stable distros like RHEL5/6. Otherwise developers have to spend far too much time working around the presence of needlessly outdated tools.
[adding bug-gnu-gettext] On 04/25/2012 07:04 AM, Jim Meyering wrote:
*** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.18 but the autoconf macros are from gettext version 0.17
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've done likewise. In fact, it looks like the Makefile.in.in from 0.18 is _already_ taking pains to be back-compatible to an 0.17 toolchain; witness constructs like:
@@ -395,9 +402,15 @@ tmpdir=`pwd`; \ echo "$$lang:"; \ test "$(srcdir)" = . && cdcmd="" || cdcmd="cd $(srcdir) && "; \ - echo "$${cdcmd}$(MSGMERGE) $$lang.po $(DOMAIN).pot -o $$lang.new.po"; \ + echo "$${cdcmd}$(MSGMERGE) $(MSGMERGE_OPTIONS) --lang=$$lang $$lang.po $(DOMAIN).pot -o $$lang.new.po"; \ cd $(srcdir); \ - if $(MSGMERGE) $$lang.po $(DOMAIN).pot -o $$tmpdir/$$lang.new.po; then \ + if { case `$(MSGMERGE) --version | sed 1q | sed -e 's,^[^0-9]*,,'` in \ + '' | 0.[0-9] | 0.[0-9].* | 0.1[0-7] | 0.1[0-7].*) \ + $(MSGMERGE) $(MSGMERGE_OPTIONS) -o $$tmpdir/$$lang.new.po $$lang.po $(DOMAIN).pot;; \ + *) \ + $(MSGMERGE) $(MSGMERGE_OPTIONS) --lang=$$lang -o $$tmpdir/$$lang.new.po $$lang.po $(DOMAIN).pot;; \ + esac; \ + }; then \
where the 0.18 version of Makefile.in.in is catering to both msgmerge 0.17 (where lang was a positional argument) and msgmerge 0.18 (where --lang is an option)
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.
It looks like modern gettext (from 0.17 onwards) is trying to be specifically aware of back-compat issues, at which point, the version mismatch check is too strict (rather than requiring strict equality, you should instead be checking for a one-way inequality - as long as the Makefile.in.in version is the same _or newer_ than the m4 macros that were used during configure, then it has been designed to work with the older version of gettext hard-coded into configure). If we can have gettext promise to maintain this back-compat, then we can rework the gnulib DEPENDENCIES file to specifically state gettext 0.17 or newer, rather than its current bleeding-edge recommendation of only the latest gettext.
[*] 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.
Precisely - it looks like as of gettext 0.17, we settled on enough of an API that the gettext 0.18 Makefile.in.in was still able to satisfy the needs of the 0.17 setup, once you can get past the version mismatch error checking. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Hello Eric, I still met this issue on latest upstream HEAD(f78024b) when compiling libvirt: Making all in po make[2]: Entering directory `/home/ajia/Workspace/libvirt/po' *** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.17 but the autoconf macros are from gettext version 0.18 make[2]: *** [check-macro-version] Error 1 Regards, Alex ----- Original Message ----- From: "Eric Blake" <eblake@redhat.com> To: "Jim Meyering" <jim@meyering.net> Cc: libvir-list@redhat.com, bug-gnu-gettext@gnu.org, "Peter Krempa" <pkrempa@redhat.com>, "bug-gnulib" <bug-gnulib@gnu.org> Sent: Thursday, April 26, 2012 12:45:29 AM Subject: Re: [libvirt] [PATCH] build: Fix version of gettext macros [adding bug-gnu-gettext] On 04/25/2012 07:04 AM, Jim Meyering wrote:
*** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.18 but the autoconf macros are from gettext version 0.17
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've done likewise. In fact, it looks like the Makefile.in.in from 0.18 is _already_ taking pains to be back-compatible to an 0.17 toolchain; witness constructs like:
@@ -395,9 +402,15 @@ tmpdir=`pwd`; \ echo "$$lang:"; \ test "$(srcdir)" = . && cdcmd="" || cdcmd="cd $(srcdir) && "; \ - echo "$${cdcmd}$(MSGMERGE) $$lang.po $(DOMAIN).pot -o $$lang.new.po"; \ + echo "$${cdcmd}$(MSGMERGE) $(MSGMERGE_OPTIONS) --lang=$$lang $$lang.po $(DOMAIN).pot -o $$lang.new.po"; \ cd $(srcdir); \ - if $(MSGMERGE) $$lang.po $(DOMAIN).pot -o $$tmpdir/$$lang.new.po; then \ + if { case `$(MSGMERGE) --version | sed 1q | sed -e 's,^[^0-9]*,,'` in \ + '' | 0.[0-9] | 0.[0-9].* | 0.1[0-7] | 0.1[0-7].*) \ + $(MSGMERGE) $(MSGMERGE_OPTIONS) -o $$tmpdir/$$lang.new.po $$lang.po $(DOMAIN).pot;; \ + *) \ + $(MSGMERGE) $(MSGMERGE_OPTIONS) --lang=$$lang -o $$tmpdir/$$lang.new.po $$lang.po $(DOMAIN).pot;; \ + esac; \ + }; then \
where the 0.18 version of Makefile.in.in is catering to both msgmerge 0.17 (where lang was a positional argument) and msgmerge 0.18 (where --lang is an option)
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.
It looks like modern gettext (from 0.17 onwards) is trying to be specifically aware of back-compat issues, at which point, the version mismatch check is too strict (rather than requiring strict equality, you should instead be checking for a one-way inequality - as long as the Makefile.in.in version is the same _or newer_ than the m4 macros that were used during configure, then it has been designed to work with the older version of gettext hard-coded into configure). If we can have gettext promise to maintain this back-compat, then we can rework the gnulib DEPENDENCIES file to specifically state gettext 0.17 or newer, rather than its current bleeding-edge recommendation of only the latest gettext.
[*] 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.
Precisely - it looks like as of gettext 0.17, we settled on enough of an API that the gettext 0.18 Makefile.in.in was still able to satisfy the needs of the 0.17 setup, once you can get past the version mismatch error checking. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[trimming cc's] On 04/25/2012 09:18 PM, Alex Jia wrote:
Hello Eric, I still met this issue on latest upstream HEAD(f78024b) when compiling libvirt:
Making all in po make[2]: Entering directory `/home/ajia/Workspace/libvirt/po' *** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.17 but the autoconf macros are from gettext version 0.18 make[2]: *** [check-macro-version] Error 1
Per my message in commit bae13129c: If you have already built in the window where libvirt required 0.18, be aware that incremental updates may run into problems: this is because 'autopoint --force' will not downgrade m4/po.m4 back to an older version, but it must be downgraded back to 0.17 levels to work with this patch. You may either manually remove that file then rerun bootstrap, or it may prove easier to just clean up all non-git files to start from a clean slate. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 04/26/2012 08:50 PM, Eric Blake wrote:
[trimming cc's]
On 04/25/2012 09:18 PM, Alex Jia wrote:
Hello Eric, I still met this issue on latest upstream HEAD(f78024b) when compiling libvirt:
Making all in po make[2]: Entering directory `/home/ajia/Workspace/libvirt/po' *** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.17 but the autoconf macros are from gettext version 0.18 make[2]: *** [check-macro-version] Error 1 Per my message in commit bae13129c:
If you have already built in the window where libvirt required 0.18, be aware that incremental updates may run into problems: this is because 'autopoint --force' will not downgrade m4/po.m4 back to an older version, but it must be downgraded back to 0.17 levels to work with this patch. You may either manually remove that file then rerun bootstrap, or it may prove easier to just clean up all non-git files to start from a clean slate.
I missed the mail :-(, It's very clear for me, thanks a lot.
participants (5)
-
Alex Jia -
Daniel P. Berrange -
Eric Blake -
Jim Meyering -
Peter Krempa