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.