Re: [libav-devel] [PATCH] configure: fail if an element is explicitely configured but dependencies are not enabled
Reinhard Tartler writes: > On Sun, Apr 03, 2011 at 15:42:43 (CEST), Måns Rullgård wrote: > >> 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. > > Can we have a switch (not necessarily a configure switch) to change > policy 2? > > Background: The configure line in the debian package is awfully long > because I try to enable any external libraries that are available in > Debian, which makes /usr/bin/ffmpeg output a configuration string of > several lines. Weren't we going to prune the default console spam? -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: fail if an element is explicitely configured but dependencies are not enabled
On 04/07/2011 07:08 AM, Reinhard Tartler wrote: > On Sun, Apr 03, 2011 at 15:42:43 (CEST), Måns Rullgård wrote: > >> 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. > > Can we have a switch (not necessarily a configure switch) to change > policy 2? > > Background: The configure line in the debian package is awfully long > because I try to enable any external libraries that are available in > Debian, which makes /usr/bin/ffmpeg output a configuration string of > several lines. I'd rather not, having automagic deps is a bane in the long run IMHO. What about providing an --enable-everything if you are positive it would help your case? lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: fail if an element is explicitely configured but dependencies are not enabled
On Sun, Apr 03, 2011 at 15:42:43 (CEST), Måns Rullgård wrote: > 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. Can we have a switch (not necessarily a configure switch) to change policy 2? Background: The configure line in the debian package is awfully long because I try to enable any external libraries that are available in Debian, which makes /usr/bin/ffmpeg output a configuration string of several lines. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: fail if an element is explicitely configured but dependencies are not enabled
On date Sunday 2011-04-03 19:24:54 +0200, Luca Barbato wrote: > On 04/03/2011 06:12 PM, Måns Rullgård wrote: > > Where did the user learn that a libx264 encoder exists in the first place? > > Regarding libz and png and bz2 and mkv might be useful dust off your > patch and maybe consider another. +1, I note that on *-user lists this is indeed a common problem (and I'm willing to change the provided patch in case there are problems with its implementation). -- Suggerimento casuale gulch #8 Unix, perché un click non è mai abbastanza veloce! -- Jacob Sparre ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: fail if an element is explicitely configured but dependencies are not enabled
On 04/03/2011 06:12 PM, Måns Rullgård wrote: > Where did the user learn that a libx264 encoder exists in the first place? Regarding libz and png and bz2 and mkv might be useful dust off your patch and maybe consider another. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: fail if an element is explicitely configured but dependencies are not enabled
Stefano Sabatini writes: > On date Sunday 2011-04-03 15:54:48 +0100, Måns Rullgård wrote: >> Stefano Sabatini writes: > [...] >> >> Thus far, nobody has complained about this. Until someone does, I'm not >> >> changing it. Your meta-complaint does not count. >> > >> > http://thread.gmane.org/gmane.comp.video.ffmpeg.user/30661/focus=30668 >> > http://thread.gmane.org/gmane.comp.video.ffmpeg.user/30778/focus=30779 >> > >> > Both users complained about --enable-filter=drawtext, but the same >> > applies to other components, for example I find >> > --enable-encoder=libx264 not enabling the libx264 encoder and not >> > failing quite counter-intuitive. >> >> Then the documentation is insufficient. Wherever the user learned of >> the libx264 encoder should document its dependencies as well. > > Reading documentation is the last user resort (when all else fails), > but we should avoid to make documentation necessary at all if an > intuitive behavior can be implemented. Where did the user learn that a libx264 encoder exists in the first place? -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: fail if an element is explicitely configured but dependencies are not enabled
On date Sunday 2011-04-03 15:54:48 +0100, Måns Rullgård wrote: > Stefano Sabatini writes: [...] > >> Thus far, nobody has complained about this. Until someone does, I'm not > >> changing it. Your meta-complaint does not count. > > > > http://thread.gmane.org/gmane.comp.video.ffmpeg.user/30661/focus=30668 > > http://thread.gmane.org/gmane.comp.video.ffmpeg.user/30778/focus=30779 > > > > Both users complained about --enable-filter=drawtext, but the same > > applies to other components, for example I find > > --enable-encoder=libx264 not enabling the libx264 encoder and not > > failing quite counter-intuitive. > > Then the documentation is insufficient. Wherever the user learned of > the libx264 encoder should document its dependencies as well. Reading documentation is the last user resort (when all else fails), but we should avoid to make documentation necessary at all if an intuitive behavior can be implemented. > You seem to like writing docs, so get started. This is a common misconception, that is like saying that since someone takes often the bus then he likes to take the bus, and any half-decent English speaker could do better than me, but I also like doing useful stuff and adding documentation is useful most of the times (and apparently I have nothing better to do... ;-)). -- Computers are unreliable, but humans are even more unreliable. Any system which depends on human reliability is unreliable. -- Gilb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: fail if an element is explicitely configured but dependencies are not enabled
Stefano Sabatini writes: > On date Sunday 2011-04-03 14:42:43 +0100, Måns Rullgård wrote: >> Stefano Sabatini writes: > [...] >> > 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. > > This is not changed by the patch, the raised issue is different, and > is that explicitely enabling an element should make configure issues > some warning. > > Indeed the user doesn't know nothing about the internal dependencies, > but when she types --enable-thing=foobar she expects the element to > be enabled. > >> Thus far, nobody has complained about this. Until someone does, I'm not >> changing it. Your meta-complaint does not count. > > http://thread.gmane.org/gmane.comp.video.ffmpeg.user/30661/focus=30668 > http://thread.gmane.org/gmane.comp.video.ffmpeg.user/30778/focus=30779 > > Both users complained about --enable-filter=drawtext, but the same > applies to other components, for example I find > --enable-encoder=libx264 not enabling the libx264 encoder and not > failing quite counter-intuitive. Then the documentation is insufficient. Wherever the user learned of the libx264 encoder should document its dependencies as well. You seem to like writing docs, so get started. -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: fail if an element is explicitely configured but dependencies are not enabled
On date Sunday 2011-04-03 14:42:43 +0100, Måns Rullgård wrote: > Stefano Sabatini writes: [...] > > 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. This is not changed by the patch, the raised issue is different, and is that explicitely enabling an element should make configure issues some warning. Indeed the user doesn't know nothing about the internal dependencies, but when she types --enable-thing=foobar she expects the element to be enabled. > Thus far, nobody has complained about this. Until someone does, I'm not > changing it. Your meta-complaint does not count. http://thread.gmane.org/gmane.comp.video.ffmpeg.user/30661/focus=30668 http://thread.gmane.org/gmane.comp.video.ffmpeg.user/30778/focus=30779 Both users complained about --enable-filter=drawtext, but the same applies to other components, for example I find --enable-encoder=libx264 not enabling the libx264 encoder and not failing quite counter-intuitive. (And not this is not a serious issue, consider this like a "paperclip"/bikeshed issue). ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: fail if an element is explicitely configured but dependencies are not enabled
> > 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. > I can not agree with you. This is a really common problem than 'something doesn't work' just because build script say NO any error and even no warning for options that user EXPLICITLY turned on. If I want to build libraries within PNG support I want to see an error with --enable-zlib flag if zlib not found for whatever reason. But today I forced to check configure output *each time* to be sure that all options important to me are not silently ignored/disabled by build system! I can understand 'everything is enabled by default'. I can understand the --disable-* flags. But I really can't understand why --enable-* flags may be 'ignored' by configure. --- Kirill Gavrilov, Software designer. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: fail if an element is explicitely configured but dependencies are not enabled
Stefano Sabatini writes: > On date Sunday 2011-04-03 12:55:25 +0100, Måns Rullgård wrote: >> Stefano Sabatini 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 >> > 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 m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: fail if an element is explicitely configured but dependencies are not enabled
On date Sunday 2011-04-03 12:55:25 +0100, Måns Rullgård wrote: > Stefano Sabatini 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 > > 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 libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: fail if an element is explicitely configured but dependencies are not enabled
Stefano Sabatini 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 > 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. -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: fail if an element is explicitely configured but dependencies are not enabled
On 04/03/2011 12:32 PM, Stefano Sabatini wrote: > From 02899171d5c81f55460d59a40b68e65fecff493a Mon Sep 17 00:00:00 2001 > From: Stefano Sabatini > 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. The idea looks nice to me, it is a change of behavior that might or might not upset some users, someone might say. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] configure: fail if an element is explicitely configured but dependencies are not enabled
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
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.
Signed-off-by: Stefano Sabatini
---
configure | 33 +
1 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index 88b9058..fd38d4f 100755
--- a/configure
+++ b/configure
@@ -390,10 +390,19 @@ enable(){
set_all yes $*
}
+enable_strong(){
+set_all yes+ $*
+}
+
disable(){
set_all no $*
}
+# same as disable
+disable_strong(){
+set_all no $*
+}
+
enable_weak(){
set_weak yes $*
}
@@ -437,9 +446,14 @@ enable_deep_weak(){
enable_weak $*
}
+enabled_strong(){
+test "${1#!}" = "$1" && op== || op=!=
+eval test "x\$${1#!}" $op "xyes+"
+}
+
enabled(){
test "${1#!}" = "$1" && op== || op=!=
-eval test "x\$${1#!}" $op "xyes"
+enabled_strong $1 || eval test "x\$${1#!}" $op "xyes"
}
disabled(){
@@ -505,6 +519,7 @@ check_deps(){
check_deps $dep_all $dep_any $dep_sel $dep_sgs $dep_ifa $dep_ifn
popvar cfg dep_all dep_any dep_sel dep_sgs dep_ifa dep_ifn
+eval ${cfg}_precheck=\$$cfg
[ -n "$dep_ifa" ] && { enabled_all $dep_ifa && enable_weak $cfg; }
[ -n "$dep_ifn" ] && { enabled_any $dep_ifn && enable_weak $cfg; }
enabled_all $dep_all || disable $cfg
@@ -518,6 +533,16 @@ check_deps(){
enable_deep_weak $dep_sgs
fi
+if enabled_strong ${cfg}_precheck && disabled $cfg; then
+eval cfg_deps=\$${cfg}_deps
+sep=""
+for dep in $cfg_deps; do
+! enabled $dep && not_enabled_deps="${not_enabled_deps}${sep}${dep}"
+sep=" "
+done
+die "Element '$cfg' explicitely enabled but its dependencies '$not_enabled_deps' are not enabled".
+fi
+
disable ${cfg}_checking
done
}
@@ -1782,15 +1807,15 @@ for opt do
is_in "${thing}s" $COMPONENT_LIST || die_unknown "$opt"
eval list=\$$(toupper $thing)_LIST
name=$(echo "${optval}" | sed "s/,/_${thing}|/g")_${thing}
-$action $(filter "$name" $list)
+${action}_strong $(filter "$name" $list)
;;
--enable-?*|--disable-?*)
eval $(echo "$opt" | sed 's/--/action=/;s/-/ option=/;s/-/_/g')
if is_in $option $COMPONENT_LIST; then
test $action = disable && action=unset
-eval $action \$$(toupper ${option%s})_LIST
+eval ${action}_strong \$$(toupper ${option%s})_LIST
elif is_in $option $CMDLINE_SELECT; then
-$action $option
+${action}_strong $option
else
die_unknown $opt
fi
--
1.7.2.3
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
