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

[Michael Niedermayer]

On Tue, Feb 05, 2019 at 11:20:03AM +0100, Bodecs Bela wrote:
> 
> 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?

I think this goes in the right direction but it is too limited.

The problem if i understand it correctly is that there are 2 semantically
different "commands" the user can give configure.

1. feature F should be enabled or disabled, the user wants that, the user
   wants to know via easy detectable failure if that fails
   
2. The user doesnt actually care about F but wants it to be enabled/disabled
   if possible.
   One use case is to disable all and then enable one. The user doesnt 
   actually want ALL to be disabled its instead part of the "language"
   used to specify what the user wants enabled

a "soft" enable/disable would solve this, where a hard en/disable causes
failure if not achieved a soft one can be discarded with a warning if it
cannot be achieved

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190205/ba14b79a/attachment.sig>