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

Carl Eugen Hoyos ceffmpeg at gmail.com
Tue Feb 5 13:28:19 EET 2019


2019-02-05 10:13 GMT+01:00, Hendrik Leppkes <h.leppkes at gmail.com>:
> On Tue, Feb 5, 2019 at 2:43 AM Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>>
>> 2019-02-05 1:13 GMT+01:00, Hendrik Leppkes <h.leppkes at gmail.com>:
>> > On Tue, Feb 5, 2019 at 1:01 AM Carl Eugen Hoyos <ceffmpeg at gmail.com>
>> > wrote:
>> >>
>> >> 2019-02-05 0:53 GMT+01:00, Marton Balint <cus at passwd.hu>:
>> >> >
>> >> >
>> >> > On Tue, 5 Feb 2019, Carl Eugen Hoyos wrote:
>> >> >
>> >> >> 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).
>> >> >
>> >> > Could you give a more concrete example? I am not sure I
>> >> > understand what you mean.
>> >>
>> >> $ ./configure --disable-everything --enable-bsf=prores_metadata
>> >> currently does not fail for current FFmpeg and 936d18fb, this
>> >> would change for future new features with your patch.
>> >>
>> >
>> > What sort of testing would involve trying to enable a certain
>> > component, and then *succeeding* when the component does not exist?
>>
>> Several regression tests have needed that in the past, I find it
>> strange that you seem to imply this will not happen in the
>> future.
>> Or is that not what you were saying?
>>
>
> I'm trying to understand what type of test you are running that would
> need this. Please explain isntead of saying "something needs this".
> It just confuses me that any test would be meaningful if you try to
> enable a component and end up with a build without it even present.

Bugs exist that need --enable-feature=foo to be reproducible with a
later version of FFmpeg while they were reproducible with older
FFmpeg before foo existed.

Carl Eugen


More information about the ffmpeg-devel mailing list