On 1/23/19 10:33 AM, Daniel P. Berrangé wrote:
> On Tue, Jan 22, 2019 at 07:20:35PM +0000, Peter Maydell wrote:
>> On Tue, 22 Jan 2019 at 19:05, Philippe Mathieu-Daudé <phi...@redhat.com>
>> wrote:
>>>
>>> Currently if we try to build QEMU on OpenBSD with SDL disabled, we get:
>>>
>>> $ ./configure --cc=x86_64-unknown-openbsd6.1-gcc-4.9.4 --python=python2.7
>>> --disable-sdl
>>>
>>> ERROR: sdl not found or disabled, can not use sdl audio driver
>>>
>>> Since SDL is not a requirement for OpenBSD, let it be optional (we remove
>>> it from $audio_drv_list but it stays available in $audio_possible_drivers).
>>> If no audio backends are available, QEMU falls back to the null driver.
>>
>>> --- a/configure
>>> +++ b/configure
>>> @@ -828,7 +828,7 @@ NetBSD)
>>> OpenBSD)
>>> bsd="yes"
>>> make="${MAKE-gmake}"
>>> - audio_drv_list="sdl"
>>> + audio_drv_list=""
>>> audio_possible_drivers="sdl"
>>> HOST_VARIANT_DIR="openbsd"
>>> supported_os="yes"
>>
>> This will mean that configure will by default not enable
>> a real audio backend, even if we do have sdl.
>>
>> Looking at the logic, "audio_possible_drivers" is only
>> used for printing the help message. The thing that drives
>> which audio drivers to test with is "audio_drv_list",
>> and the expectation is that you put things on that only
>> if it's possible to build with them. (For instance
>> we only add 'dsound' for mingw if the dsound.h header is
>> present, and so on.)
Yes sorry I missed that Peter :S
>> So we need to do one of:
>> (1) only put "sdl" into audio_drv_list if SDL is
>> available (this probably doesn't work as we haven't
>> probed for SDL at the point where we initialize it)
>> (2) have the sdl probe delete "sdl" from audio_drv_list
>> if the probe fails
>
> This one sounds reasonable to me.
I went this way, but encountered unexpected problems, which makes me
wonder who really use OpenBSD... Anyway the discussion deserves another
thread.
>> (3) some more complicated restructuring :-)
>> (eg rather than having audio_drv_list be set to an
>> initial list based on the host OS, just have a full
>> list of drivers, insist that each has a proper probe
>> routine, and use whichever ones we can successfully
>> probe)
>
>
> Regards,
> Daniel
>
