Re: regression in meson build, AC_PATH_PROG lost

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.