Re: driver_remote option defaults to auto

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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
> `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 currently it seems there is no effort to auto
> determine driver_remote. I think it is interesting because
> sasl seems required remote_driver to have a value of enabled...


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

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.


Attachment: signature.asc
Description: PGP signature

[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux