4:50 a.m.
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
4:57 a.m.
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 :|
5:01 a.m.
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
7:22 a.m.
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
7:52 a.m.
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 :|
9:50 a.m.
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
11:27 p.m.
[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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
8:04 a.m.
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.
8:10 a.m.
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 :|
10:11 a.m.
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:
http://people.redhat.com/meyering/autotools-install
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-autopo...;.
+ 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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
10:38 a.m.
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:
>
> http://people.redhat.com/meyering/autotools-install
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-autopo...;.
+ 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.
11:45 a.m.
[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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
10:18 p.m.
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(a)redhat.com>
To: "Jim Meyering" <jim(a)meyering.net>
Cc: libvir-list(a)redhat.com, bug-gnu-gettext(a)gnu.org, "Peter Krempa"
<pkrempa(a)redhat.com>, "bug-gnulib" <bug-gnulib(a)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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
7:50 a.m.
[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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
4:47 a.m.
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.
4592
days inactive
4596
days old
14 comments
5 participants
participants (5)
-
Alex Jia -
Daniel P. Berrange -
Eric Blake -
Jim Meyering -
Peter Krempa