Re: [Qemu-devel] [PATCH] configure: Let SDL support be optional on OpenBSD

[Philippe Mathieu-Daudé]

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é <address@hidden> 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
>