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

Hendrik Leppkes h.leppkes at gmail.com
Tue Feb 5 11:13:41 EET 2019


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.

- Hendrik


More information about the ffmpeg-devel mailing list