Re: driver_remote option defaults to auto

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


On Mon, Jun 21, 2021 at 11:35:24AM +0200, Pavel Hrdina wrote:
> 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...
> 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.

I will add that, when packaging libvirt, it's recommended to
explicitly pass -Dfeature=enabled/disabled for each and every feature
instead of relying on libvirt's autodetection getting things right:
this ensures that the build either exactly matches your expectations
or fails with a useful error message.

Andrea Bolognani / Red Hat / Virtualization

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

  Powered by Linux