2019-02-05 10:13 GMT+01:00, Hendrik Leppkes <h.lepp...@gmail.com>: > On Tue, Feb 5, 2019 at 2:43 AM Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >> >> 2019-02-05 1:13 GMT+01:00, Hendrik Leppkes <h.lepp...@gmail.com>: >> > On Tue, Feb 5, 2019 at 1:01 AM Carl Eugen Hoyos <ceffm...@gmail.com> >> > wrote: >> >> >> >> 2019-02-05 0:53 GMT+01:00, Marton Balint <c...@passwd.hu>: >> >> > >> >> > >> >> > On Tue, 5 Feb 2019, Carl Eugen Hoyos wrote: >> >> > >> >> >> 2019-02-03 16:24 GMT+01:00, Marton Balint <c...@passwd.hu>: >> >> >>> >> >> >>> >> >> >>> On Sun, 3 Feb 2019, Carl Eugen Hoyos wrote: >> >> >>> >> >> >>>> 2019-01-28 2:00 GMT+01:00, Marton Balint <c...@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 <c...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel