On Mon, 2021-04-19 at 19:14 +0200, Pavel Hrdina wrote:
> Recent attempt to add a lot of meson options to specify different
> runtime paths motivated me enough to cleanup this from meson.
>
> Changes in v2:
> - split and rework patch 16/17 to address review comments
> - added a new patch to cleanup libvirt.spec.in file
Overall I like this change, if nothing else because it finally cleans
up the mess where some optional programs would be detected at build
time while others would be detected at runtime, with no apparent
reason for going one way rather than the other.
The only concern I have, which is one I have expressed already in the
past, is that it will now be harder for users and packagers alike to
figure out that they don't have a certain optional program installed:
AFAICT, after your patches the only way would be to try using each
feature and look out for errors.
Can we still check for the availability of these commands at build
time and simply report their presence? I'm thinking of something like
optional_runtime_programs = [
'dmidecode',
'dnsmasq',
...
]
which would be reported in the Meson summary as
Optional runtime programs:
dmidecode: YES
dnsmasq: NO
...
Then, for each of these commands, we'd also create a macro
definition in meson-config.h like
#define PROGRAM_DMIDECODE "dmidecode"
#define PROGRAM_DNSMASQ "dnsmasq"
...
and use those in the various C functions instead of the ad-hoc,
private defines that are currently sprinkled throughout the code.
Note that said macro would *not* be defined conditionally based on
whether the optional program was found at build time: the intention
is simply to have a single location where information about all these
optional runtime programs are stored, instead of forcing users and
packagers to go hunting for them across all of libvirt, potentially
missing a bunch in the process.
What do you think?
--
Andrea Bolognani / Red Hat / Virtualization
