On Mon, 25 Jul 2016, Diego Biurrun wrote:
On Fri, Jul 15, 2016 at 01:43:14PM +0300, Martin Storsjö wrote:
--- a/configure
+++ b/configure
@@ -4565,9 +4566,12 @@ for func in $MATH_FUNCS; do
+# This needs to be evaluated here instead of via the generic mechanism
+# (setting dyn_lib_open_deps_any) since we want it set here
+enabled_any dlopen LoadLibrary && enable dyn_lib_open || disable dyn_lib_open
I'm not convinced this is necessary or better than adding dyn_libs_open
to avisynth_demuxer_deps.
Hmm, what behaviour would you get then, if you do e.g. --enable-avisynth
but don't have dyn_libs_open available - would you get a configure error,
or a build without avisynth?
I don't particularly mind all that much though.
# these are off by default, so fail if requested and not available
-enabled avisynth && { check_lib2 "avisynth/avisynth_c.h windows.h"
LoadLibrary ||
- check_lib2 "avxsynth/avxsynth_c.h dlfcn.h"
dlopen -ldl ||
+enabled avisynth && { { check_header "avisynth/avisynth_c.h" &&
enabled dyn_lib_open; } ||
die "ERROR: LoadLibrary/dlopen not found, or
avisynth header not found"; }
Did you just drop support for avxsynth?
Whoops, will amend.
Also, checking for dyn_lib_open first would slightly speed up configure
when dyn_lib_open is not available.
I think that's ricing, optimizing for the case when this enters the fail
path. But the better question is which of them looks better in the code.
E.g. if one does it like this:
enabled avisynth && { { { check_header "avisynth/avisynth_c.h" ||
check_header "avxsynth/avxsynth_c.h"; } &&
enabled dyn_lib_open; } ||
die "ERROR: LoadLibrary/dlopen not found, or avisynth
header not found"; }
I guess it doesn't matter much if checking the headers or dyn_lib_open
first.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
