Re: [libvirt] [PATCH] build: Fix version of gettext macros
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
Attachments:
- signature.asc (application/pgp-signature — 620 bytes)