Re: [libvirt] [PATCH] autogen: work around BSD toolchain snafu
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
Attachments:
- signature.asc (application/pgp-signature — 621 bytes)