Re: [libvirt] [PATCH] build: Fix version of gettext macros

[eblake]

[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@...    [phone]
Libvirt virtualization library http://libvirt.org

[Jim Meyering]

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.

[Daniel P. Berrange-2]

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 :|

[eblake]

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-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@...    [phone]
Libvirt virtualization library http://libvirt.org

[Jim Meyering]

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-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.

[eblake]

[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@...    [phone]
Libvirt virtualization library http://libvirt.org

[eblake]

[trimming cc's for now]

On 04/25/2012 09:38 AM, Jim Meyering wrote:
>> 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.

gnulib-local doesn't work.  The change has to be to bootstrap, but
'./bootstrap --sync-bootstrap' doesn't honor gnulib-local (rather, it
directly copies from the current state of the gnulib submodule).

Is it worth my time trying to teach './bootstrap --sync-bootstrap' to
honor gnulib-local diffs?  Maybe not; after all, the reason we first
added the 'cat' (aka fancy 'cp') to bootstrap in the first place was
because of bison using the 'gettext' module.  We've already stated that
if you use the 'gettext' module, you want the latest-and-greatest
gettext, at all costs (and the cp makes sense, as it will then alert you
if your installed gettext is out of date with the latest release).  But
if you use the 'gettext-h' module, you want to use gettext, but no
necessarily the latest and greatest, in which case, the Makefile.in.in
which should have been installed by our early run of autopoint should
still be adequate.

In other words, I'm thinking this patch is appropriate (I've tested it
on libvirt, which uses gettext-h, and on bison which uses gettext).

diff --git i/build-aux/bootstrap w/build-aux/bootstrap
index 5aa73cc..6b45868 100755
--- i/build-aux/bootstrap
+++ w/build-aux/bootstrap
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Print a version string.
-scriptversion=2012-04-19.22; # UTC
+scriptversion=2012-04-25.17; # UTC

 # Bootstrap this package from checked-out sources.

@@ -873,7 +873,15 @@ 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
+  # If the 'gettext' module is in use, grab the latest Makefile.in.in.
+  # If only the 'gettext-h' module is in use, assume autopoint already
+  # put the correct version of this file into place.
+  case $gnulib_modules in
+  *gettext-h*) ;;
+  *gettext*)
+    cp $GNULIB_SRCDIR/build-aux/po/Makefile.in.in po/Makefile.in.in ||
exit 1
+    ;;
+  esac

   if test -d runtime-po; then
     # Similarly for runtime-po/Makevars, but not quite the same.


--
Eric Blake   eblake@...    [phone]
Libvirt virtualization library http://libvirt.org

[Jim Meyering]

Eric Blake wrote:

> [trimming cc's for now]
>
> On 04/25/2012 09:38 AM, Jim Meyering wrote:
>>> 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.
>
> gnulib-local doesn't work.  The change has to be to bootstrap, but
> './bootstrap --sync-bootstrap' doesn't honor gnulib-local (rather, it
> directly copies from the current state of the gnulib submodule).
>
> Is it worth my time trying to teach './bootstrap --sync-bootstrap' to
> honor gnulib-local diffs?  Maybe not; after all, the reason we first

That doesn't seem worthwhile.

...
> In other words, I'm thinking this patch is appropriate (I've tested it
> on libvirt, which uses gettext-h, and on bison which uses gettext).

That looks good, and your testing seems to cover all bases.
Thanks for dealing with this.

> diff --git i/build-aux/bootstrap w/build-aux/bootstrap
...

> @@ -873,7 +873,15 @@ 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
> +  # If the 'gettext' module is in use, grab the latest Makefile.in.in.
> +  # If only the 'gettext-h' module is in use, assume autopoint already
> +  # put the correct version of this file into place.
> +  case $gnulib_modules in
> +  *gettext-h*) ;;
> +  *gettext*)
> +    cp $GNULIB_SRCDIR/build-aux/po/Makefile.in.in po/Makefile.in.in ||
> exit 1
> +    ;;
> +  esac

[eblake]

On 04/25/2012 12:33 PM, Jim Meyering wrote:

>> In other words, I'm thinking this patch is appropriate (I've tested it
>> on libvirt, which uses gettext-h, and on bison which uses gettext).
>
> That looks good, and your testing seems to cover all bases.
> Thanks for dealing with this.
>
>> diff --git i/build-aux/bootstrap w/build-aux/bootstrap
> ...
>> @@ -873,7 +873,15 @@ 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
>> +  # If the 'gettext' module is in use, grab the latest Makefile.in.in.
>> +  # If only the 'gettext-h' module is in use, assume autopoint already
>> +  # put the correct version of this file into place.
>> +  case $gnulib_modules in
>> +  *gettext-h*) ;;
>> +  *gettext*)
>> +    cp $GNULIB_SRCDIR/build-aux/po/Makefile.in.in po/Makefile.in.in ||
>> exit 1
>> +    ;;
>> +  esac

I've pushed this now.

--
Eric Blake   eblake@...    [phone]
Libvirt virtualization library http://libvirt.org

[ajia]

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@...>
To: "Jim Meyering" <jim@...>
Cc: libvir-list@..., bug-gnu-gettext@..., "Peter Krempa" <pkrempa@...>, "bug-gnulib" <bug-gnulib@...>
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@...    [phone]
Libvirt virtualization library http://libvirt.org


--
libvir-list mailing list
libvir-list@...
https://www.redhat.com/mailman/listinfo/libvir-list