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 || >> + 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?