On Fri, 2 Oct 2020 at 13:44, Paolo Bonzini <pbonz...@redhat.com> wrote: > > On 02/10/20 14:36, Peter Maydell wrote: > > On Fri, 2 Oct 2020 at 13:35, Peter Maydell <peter.mayd...@linaro.org> wrote: > >> > >> On Fri, 2 Oct 2020 at 13:02, Paolo Bonzini <pbonz...@redhat.com> wrote: > >>> - the workaround: just leave things as they are and add > >>> --disable-libudev to your script. > >> > >> There is no --disable-udev ! > > > > ...and there's no --disable-libudev either :-) > > You're right---I was sure I used some get_option but it's not > --disable-libudev; it's --disable-mpath. That made sense when mpath was > the only thing that used libudev, but probably now we should add a > separate --disable-libudev.
Well, this gets into the question of what --disable-foo options should be doing. They're user facing, so really they ought to be for user-facing features. So for instance: seccomp seccomp support libssh ssh block device support dmg dmg image format support gtk gtk UI are all enabling or disabling features the user might plausibly have an opinion about whether they want or not. These are bit more dubious -- they are enabling/disabling a specific library, and so the help text has had to do the translation of that for the user into "what actual feature in QEMU am I losing here if I disable this?"; libxml2 for Parallels image format libusb libusb (for usb passthrough) and then these give the user no hints at all: libpmem libpmem support libdaxctl libdaxctl support so it's not clear what they're intended for (unless it's solely for the niche use case of "work around the build machinery not correctly detecting whether the library is available"...) Having a --disable-libudev seems to me strictly worse than either (a) the build system actually being able to correctly identify that the host has a libudev available to link to (b) having an option with a name and help text that tells the user what they're actually gaining or losing by the feature being enabled/disabled thanks -- PMM
