[FFmpeg-devel] [PATCH] configure: request explicitly enabled components

[Carl Eugen Hoyos]

2019-02-05 11:20 GMT+01:00, Bodecs Bela <bodecsb at vivanet.hu>:
>
> 2019.02.05. 0:45 keltezéssel, Carl Eugen Hoyos írta:
>> 2019-02-03 16:24 GMT+01:00, Marton Balint <cus at passwd.hu>:
>>>
>>> On Sun, 3 Feb 2019, Carl Eugen Hoyos wrote:
>>>
>>>> 2019-01-28 2:00 GMT+01:00, Marton Balint <cus at passwd.hu>:
>>>>> If we enable a component but a dependant library is disabled, then the
>>>>> enabled
>>>>> component get silently disabled. Requesting all explicitly enabled
>>>>> components
>>>>> allows configure to fail and show the missing dependencies instead of
>>>>> ignoring
>>>>> our request.
>>>>>
>>>>> For example if libdav1d is not availble ./configure
>>>>> --enable-decoder=libdav1d
>>>>> succeeds but the libdav1d decoder will not be enabled. After the patch
>>>>> the
>>>>> configure line will fail with the following message:
>>>>> ERROR: libdav1d_decoder requested, but not all dependencies are
>>>>> satisfied:
>>>>> libdav1d
>>>>>
>>>>> Signed-off-by: Marton Balint <cus at passwd.hu>
>>>>> ---
>>>>>   configure | 1 +
>>>>>   1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/configure b/configure
>>>>> index e1412352fa..1f6c6a7311 100755
>>>>> --- a/configure
>>>>> +++ b/configure
>>>>> @@ -3881,6 +3881,7 @@ for opt do
>>>>>               list=$(filter "$name" $list)
>>>>>               [ "$list" = "" ] && warn "Option $opt did not match
>>>>> anything"
>>>>>               $action $list
>>>>> +            test $action = enable && request $list
>>>> I strongly suspect that this will break regression tests.
>>> You mean fate with different configure options?
>> No, I believe this would break regression tests with
>> --disable-everything (and an enable for a feature that
>> was added in the meantime and is needed to reproduce
>> the issue).
>> Please print a warning like for "--enable-decoder=foo"
>> to fix the issue you see.
>
>
> what about to have a new switch of configure script that controls the
> behaviour at missing dependencies? Something like --stop_on_missing_deps
>
> its defult value would be "no" as current state, but Marton Balint new
> patch functionality may work at "yes" state?

How would this be better than printing a warning if the feature
could not be enabled as it is already done in some situations?

Carl Eugen