Stefano Sabatini <[email protected]> writes: > On date Sunday 2011-04-03 12:55:25 +0100, Måns Rullgård wrote: >> Stefano Sabatini <[email protected]> writes: >> >> > Hi, >> > >> > sending to both lists as Mans is listed as configure maintainer in >> > FFmpeg, and I believe the patch is useful for whatever side of the >> > fork. >> > >> > Take care >> > >> > From 02899171d5c81f55460d59a40b68e65fecff493a Mon Sep 17 00:00:00 2001 >> > From: Stefano Sabatini <[email protected]> >> > Date: Sat, 2 Apr 2011 17:02:54 +0200 >> > Subject: [PATCH] configure: fail if an element is explicitely configured >> > but dependencies are not >> > >> > Make configure fail if an element is eplicitely configured but one of >> > its dependencies are not. This allows configure to explicitely warns >> > the user and fail, rather than silently disabling an explicitely >> > enabled element, which some users find confusing. >> > >> > For example now you have: >> > ./configure --enable-filter=ocv >> > Element 'ocv_filter' explicitely enabled but dependencies 'libopencv' are >> > not enabled. >> > >> > previously, the ocv filter was silently disabled with no warning. >> >> That's not how it's supposed to work. All codecs, filters, etc are >> enabled by default and disabled if their dependencies not present. Thus >> --enable-libopencv enables whatever filters depend on it unless >> otherwise disabled. Similarly, --disable-fft will disable all codecs >> which use the FFT, even if the user tries to explicitly enable them. >> It has always been like this, and nobody has complained. I see no >> reason to change it now. >> >> In addition to the above, I am not at all convinced the patch is correct >> for what it purports to do. > > I suppose we can implement two policies: > > a. when a component is explicitely enabled, all the depending > components are automatically enabled > > E.g.: > --enable-libx264 -> enable libx264-encoder, gpl > --enable-librtmp -> enable librtmp-muxer/demuxer > > b. when a component is explicitely enabled, check if the dependencies > are enabled and fail otherwise; enable a component by default if > all its dependencies are satisfied > > We currently have a mix of a. and b., and I find b. more usable and > safer, as the user becomes more aware of what she's enabling and what > not. > > For example the user wants to enable the libx264 encoder. > Currently we have: > $ configure --enable-encoder=libx264 > => success, but libx264 and the libx264-encoder are not enabled > > With the b. approach: > $ configure --enable-encoder=libx264 > => configure complains about missing gpl and libx264, and fails. > > $ configure --enable-libx264 --enable-gpl > => success, libx264-encoder is automatically enabled since its dependencies > are satisfied > > If we want to use a pure a. approach we should automatically enable > gpl (while currently we have an ad-hoc license check) which doesn't > appear like a good idea from the legal POV, adopting a hybrid approach > (as currently implemented) is confusing.
There is nothing confusing at all. Two simple rules: 1. Everything is enabled by default. 2. External libs must be explicitly enabled. Thus far, nobody has complained about this. Until someone does, I'm not changing it. Your meta-complaint does not count. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
