On 12/04/2013 01:01 AM, Roman Bogorodskiy wrote:
We found a workaround - fake the use of an intl subdirectory long enough for autopoint to get what it wants from that fallback. This workaround may eventually move upstream into gnulib's bootstrap; when it does, we can remove the hack from libvirt's autogen.sh.
It works only when the submodule is not up to date.
When running autogen.sh again it doesn't reach the 'else' clause you create intl/VERSION in, so it just runs autoreconf and fails with the same error.
Not what I was hoping to hear (and maybe gives me more incentive to set up an environment where I can reproduce the failure myself, instead of debugging remotely).
Also, I think we cannot do 'rmdir intl' because it's not empty (scripts copy over gettext sources there?), so it fails:
Hmm, I thought 'rmdir -p' would be silent for a non-empty directory; but I just confirmed that it is not. And that means that autopoint is installing files into intl on your machine - probably because more than just the AM_GNU_GETTEXT_VERSION probe failed. Ah, I see - gettext also uses autom4te to probe for AM_GNU_GETTEXT, and fails to see that we requested AM_GNU_GETTEXT([external]) and so tries to install into intl/ instead, which is what we don't want. So my attempt at a workaround is rather botched. NACK to this patch (whether in libvirt's wrapper, or in gnulib's bootstrap), and I think what I will try instead is a patch to bootstrap that fails loudly if autom4te is broken, encouraging users to install a working autom4te. Bummer that gettext hardcodes to the first 'autom4te' on PATH rather than using an ${AUTOM4TE} env-var; overriding a broken autom4te thus requires modifying PATH and sticking yet another wrapper in front of the broken autom4te version. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org