regression in meson build, AC_PATH_PROG lost

[Neal Gompa]

On Fri, Nov 13, 2020 at 8:14 AM Andrea Bolognani <abologna at redhat.com> wrote:
>
> On Fri, 2020-11-13 at 12:37 +0100, Pavel Hrdina wrote:
> > On Thu, Nov 12, 2020 at 10:40:02PM +0100, Olaf Hering wrote:
> > > Since meson does not support environment variables it seems the
> > > only way to address this is to introduce an option in
> > > meson_options.txt for each runtime executable.
> > >
> > > Will such change be accepted?
> >
> > This would be one way how to address runtime executables, currently we
> > have a lot of them. These executables are checked in order to
> > enable/disable some libvirt feature but is used only in runtime:
> >
> >     parted, bhyve, bhyvectl, bhyveload, mount, umount, mkfs, pvcreate,
> >     vgcreate, lvcreate, pvremove, vgremove, lvremove, lvchange, vgchange,
> >     vgscan, pvs, vgs, lvs, (collie|dog), vstorage, vstorage-mount, zfs,
> >     zpool, numad
> >
> > This one is even more broken as if we don't find it during build time it
> > is set to empty string and never checked in our code:
> >
> >     showmount
> >
> > These are checked during build time but if not present they are set to
> > known absolute path:
> >
> >     qemu-bridge-helper, qemu-pr-helper, slirp-helper, dbus-daemon
> >
> > And we have a list of optional_programs that are checked during build
> > time and if not present they are set to the name of the executable and
> > resolved during runtime from $PATH.
> >
> > The last executable, pkcheck, is not used during build and in runtime.
> > We only check its presence to enable/disable polkit support. We should
> > be able to simply drop this check and figure out the presence of polkit
> > using DBus only as we do for machined or logind and other DBus services
> > that we use.
> >
> > All of this was copied from autoconf except for the fact that it is no
> > longer possible to use ENV variables.
> >
> > I think we need to unify the process how we handle runtime executable
> > dependencies and possibly add meson options for them.
>
> As another data point, Debian currently carries a patch[1] which
> allows us to enable the ZFS driver without installing the ZFS
> packages in the build environment: this is necessary because, due to
> its license, ZFS is kept outside of the main Debian repository.
>
> Being able to use something like
>
>   -Dprog_zfs=/sbin/zfs -Dprog_zfspool=/sbin/zfspool
>
> to achieve the same result would allow us to drop that patch, which I
> would be *extremely* happy about :)
>
>
> [1] https://salsa.debian.org/libvirt-team/libvirt/-/blob/debian/master/debian/patches/debian/Set-defaults-for-zfs-tools.patch

The way I solved *that* specific problem was to use zfs-fuse at
build-time and have runtime work with either implementation. That
should work for you too, since Debian has zfs-fuse in main.


-- 
真実はいつも一つ！/ Always, there's only one truth!