qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] meson.build: Don't look for libudev for static builds


From: Peter Maydell
Subject: Re: [PATCH] meson.build: Don't look for libudev for static builds
Date: Fri, 2 Oct 2020 14:01:53 +0100

On Fri, 2 Oct 2020 at 13:44, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 02/10/20 14:36, Peter Maydell wrote:
> > On Fri, 2 Oct 2020 at 13:35, Peter Maydell <peter.maydell@linaro.org> wrote:
> >>
> >> On Fri, 2 Oct 2020 at 13:02, Paolo Bonzini <pbonzini@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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]