regression in meson build, AC_PATH_PROG lost

[Andrea Bolognani]

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
-- 
Andrea Bolognani / Red Hat / Virtualization