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

[Eric Blake]

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   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature