On Mon, Jul 25, 2016 at 02:13:12PM +0300, Martin Storsjö wrote:
> 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?
Depends on the avisynth check; right now a configure error. In many
cases, however, we do fail silently.
> > 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.
It certainly is. But I'm starting to worry about configure speed as it
does not run in parallel. I worry that at some point we might be like
small autotools projects where configure time dwarfs (parallel) make
time.
> 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.
Yes, pretty much the same.
Diego
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
