[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libvirt] [PATCH] build: Fix version of gettext macros
From: |
Eric Blake |
Subject: |
Re: [libvirt] [PATCH] build: Fix version of gettext macros |
Date: |
Wed, 25 Apr 2012 09:11:42 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 |
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
Re: [libvirt] [PATCH] build: Fix version of gettext macros, Eric Blake, 2012/04/25