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

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