On Tue, Feb 17, 2026 at 09:31:20AM +0000, Peter Maydell wrote: > On Tue, 17 Feb 2026 at 05:29, Sergei Heifetz <[email protected]> wrote: > > > > This patch adds the `audio` option to meson_options.txt. It is > > propagated into Kconfig as AUDIO. It is enabled by default. > > The corresponding `--disable-audio` and `--enable-audio` options > > for `configure` are also added. > > > > For now, this option does nothing. In subsequent patches, it will > > gradually disable audio in different places. The final goal is to stop > > building sources from `audio/` and `hw/audio/` and other audio-related > > files (except for some stubs). Note that this intent is different from > > `-audio none`, which mutes audio but still compiles the audio subsystem. > > Not building audio/ code makes sense, but do we really want to > stop building hw/audio code ? That's the guest facing audio > devices, and if for instance a machine type has an embedded > sound device that would require us to stop compiling that > machine. I think it would be very confusing for users if > --disable-audio meant "we will silently not build half the > Arm boards that have a pl041 in them". > > Maybe it would be better if "--disable-audio" meant "don't build > the audio backends, and everything behaves as if the user > passed -audio none" ?
Don't we already have the ability to disable individual audio backends ? Each of them relies on a different 3rd party library that we have to check for, with none of them being mandatory. I feel like we shouldn't have a "--disable-audio" at all. For backends we always go for having ways to disable individual dependencies, and for frontends we provide Kconfig for fine tuning what's enabled for a given target. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
