On Sun, Jun 20, 2021 at 05:10:40PM +0800, Jiatong Shen wrote:
Hello community,
I am looking at building and packaging libvirt source code. I am seeing
from commit
https://github.com/libvirt/libvirt/commit/83ff55b5a2618d32f623d7ca0b6f9c2...
`driver_remote` is defaulting to auto which is different from enabled
before. I am curious what does auto mean? does it mean that meson will take
over and determine if driver_remote should be enabled or we have to write
more logic in meson.build? currently it seems there is no effort to auto
determine driver_remote. I think it is interesting because
https://github.com/libvirt/libvirt/blob/54b602019d7dfa94a6c52ef7aa3abdfaa...
sasl seems required remote_driver to have a value of enabled...
Hi,
I see how this may be confusing. The current code is correct and there
is no need to change anything as this one way how it can be done with
meson.
If some option is 'feature' type and the default value is set to 'auto'
this is what meson returns:
get_option('opt').disabled() -> false
get_option('opt').auto() -> true
get_option('opt').enabled() -> false
In the case of 'driver_remote' option we have the following check:
if not get_option('driver_remote').disabled()
which means that it will disable 'driver_remote' only if user calls
meson with `-Ddriver_remote=disabled`.
If you look closer to the following lines you will see that we also
check for xdr_dep. If xdr_dep is missing and 'driver_remote' is set
to 'auto' it will not be enabled as XDR is required, but if
'driver_remote' is set to 'enabled' but user calling meson with
`-Ddriver_remote=enabled` meson will fail with proper error message.
Before the changes done by the first commit you mentioned the
'driver_remote' was always enabled and if XDR was missing it always
failed and user had to explicitly use `-Ddriver_remote=disabled` on
systems where XDR is not available or if the user was not interested
in having 'driver_remote' available.
Pavel