Thursday, May 1, 2014, 3:06:27 PM, you wrote: > On 1 May 2014 13:56, Sander Eikelenboom <li...@eikelenboom.it> wrote: >> Thursday, May 1, 2014, 1:06:35 PM, you wrote: >>> This is a lower-quality duplicate of the code we already >>> have in configure for probing whether an audio backend >>> is present (for instance it doesn't allow for the possibility >>> that the headers have been installed elsewhere). It would >>> be better to update the existing probe code to distinguish >>> between "must be present", "don't use" and "use if present" >>> for each audio driver, in the same way we do for other >>> features. Then we could just set the default list here >>> to "maybe-pa maybe-alsa oss" (syntax off the top of my >>> head, feel free to have a better idea). >> >> How bad would it be for the generic targetos case to start with: >> >> audio_drv_list == audio_possible_drivers = "oss alsa sdl esd pa" >> >> or just add the probably most used two: >> audio_drv_list = "oss alsa pa" >> >> and just let the auto probing do it's business ?
> At the moment if you put something in audio_drv_list > then configure will stop with an error if that driver > can't be probed. So putting 'pa' or 'alsa' in the > default list is a bad idea, because people whose setups > worked fine for building qemu will suddenly find they > stop working. Those thoughts only occur to me a few milliseconds after hitting the send button I think a "probe-" prefix would be more clear then the "maybe-" prefix. so "alsa" would require alsa and fail/exit the configure if the headers are not present "probe-alsa" would do the audio probe but not fail/exit the configure but just not select it for build. I will try brew something :-) > We need both behaviours -- distributions want to be able > to say "build with pulseaudio" and have the build fail > if their pulseaudio dependencies aren't set up correctly > rather than silently produce a package which won't work > in their distro. But the average person building QEMU > for their own use generally would prefer "probe for the > features but if they're not present then just don't > build the code that uses them". > thanks > -- PMM
