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.
--
Hokey religions and ancient weapons are no substitute for a good blaster at
your side.
-- Han Solo
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
