Re: [libav-devel] [PATCH] configure: Don't silently disable explicitly-enabled VAAPI

2016-09-06 Thread Luca Barbato 
On 06/09/16 10:40, Anton Khirnov wrote:
> I think the idea is to only auto-enable things that do not carry runtime
> library dependencies.
> 


* Donning his Gentoo hat

lu> Automagic dependencies are murder!


Jokes aside, yes we should not auto-enable external dependencies that
aren't expected to be part of the system.

lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] configure: Don't silently disable explicitly-enabled VAAPI

2016-09-06 Thread Anton Khirnov 
Quoting Mark Thompson (2016-09-05 13:38:19)
> ---
> On 05/09/16 12:10, Diego Biurrun  wrote:
> > Module: libav
> > Branch: master
> > Commit: 2610c9528f86286e4c6e174411a26ff5b4815cde
> > 
> > Author:Diego Biurrun 
> > Committer: Diego Biurrun 
> > Date:  Tue Mar 17 13:12:41 2015 +0100
> > 
> > configure: Move initial VAAPI check to a more sensible place
> > 
> > ...
> > @@ -4775,6 +4774,8 @@ if enabled libxcb; then
> >  add_extralibs "$xcb_event_libs $xcb_shm_libs $xcb_xfixes_libs"
> >  fi
> >  
> > +enabled vaapi && require vaapi va/va.h vaInitialize -lva
> > +
> >  enabled vaapi &&
> >  check_code cc "va/va.h" "vaCreateSurfaces(0, 0, 0, 0, 0, 0, 0, 0)" ||
> >  disable vaapi
> 
> Maybe this cleanup could go a bit further - I think the original form of the
> vaCreateSurfaces() check came from a version in ffmpeg, where VAAPI is
> autodetected rather than requiring an --enable.
> 
> Alternatively, we could let it be autodetected?  What are the criteria for
> deciding to do that?  (I see that vdpau and dxva are already.)
> 

I think the idea is to only auto-enable things that do not carry runtime
library dependencies.

-- 
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel