On Fri, 2019-11-08 at 11:24 +0000, Daniel P. Berrangé wrote:
> On Fri, Nov 08, 2019 at 12:15:53PM +0100, Andrea Bolognani wrote:
> > On Fri, 2019-11-08 at 10:04 +0000, Daniel P. Berrangé wrote:
> > > Moving this HAVE_GNU_GETTEXT_TOOLS conditional means that on OS that
> > > lack the GNU gettext impl, we are no longer able to 'make install'
> > > the translation files, despite having them prebuilt & bundled in the
> > > tarball.
> > >
> > > IIRC, this affects any non-Linux host.
> >
> > We install GNU gettext both on FreeBSD and on macOS, so it shouldn't
> > really be a problem I think? To me it doesn't seem much different
> > from mandating the use of GNU make, which we already do.
>
> Where we do that on macOS ? When I first did this new po/Makefile.am
> impl we didn't have GNU gettext on macOS at least, and I don't see us
> installing anything special in the travis config.
You're right that we don't install it explicitly: we used to, but we
stopped doing so with
commit f28ed2e98c8307655ea53ad5cd1fe5e539cf626d
Author: Andrea Bolognani <abologna@xxxxxxxxxx>
Date: Mon Dec 4 15:54:59 2017 +0100
travis: Don't try to install brew packages twice
gettext, gnutls and libgcrypt are already installed on the
system, so we don't need to request their installation.
Signed-off-by: Andrea Bolognani <abologna@xxxxxxxxxx>
Reviewed-by: Daniel P. Berrange <berrange@xxxxxxxxxx>
Looking at that commit now I'm not sure why I even thought that would
be a good idea? ¯\_(ツ)_/¯ Then again, we're not exactly as
comprehensive in our handling of macOS packages as we are on other
platforms, in part because we're not building our own images but
rather using whatever Travis CI provides us with.
Anyway, GNU gettext is dragged in as a dependency of GLib these days
and we're already making sure we actually use it:
- compiler: clang
language: c
os: osx
env:
- PATH="/usr/local/opt/gettext/bin:..."
> If we can assume GNU gettext though, we should enforce that upfront in
> the configure script checks and get rid of the conditional entirely
That would make perfect sense to me.
--
Andrea Bolognani / Red Hat / Virtualization
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
