[FFmpeg-devel] [PATCH]Possible configure support for VDPAU

[Diego Biurrun]

On Mon, Feb 09, 2009 at 02:15:23AM +0200, Ivan Kalvachev wrote:
> On 2/9/09, Diego Biurrun <diego at biurrun.de> wrote:
> > On Mon, Feb 09, 2009 at 02:06:21AM +0200, Ivan Kalvachev wrote:
> >> On 1/6/09, M?ns Rullg?rd <mans at mansr.com> wrote:
> >> >
> >> > Gwenole Beauchesne wrote:
> >> >>
> >> >> On Tue, 6 Jan 2009, M?ns Rullg?rd wrote:
> >> >>
> >> >>>> I would like to avoid plain header name provided by the vendor, even
> >> >>>> if
> >> >>>> it's installed under another directory. i.e. avoid plain vdpau.h, or
> >> >>>> plain
> >> >>>> va.h (or other_kind_hwaccel_api.h) in the future.
> >> >>>>
> >> >>>> e.g. for VA API, va.h is currently not installed under a specific va/
> >> >>>> directory. So, a #include "va.h" would be ambiguous.
> >> >>>
> >> >>> Yes!  Now we can have a code-gem like this:
> >> >>>
> >> >>> #include <va.h>
> >> >>> #include "va.h"
> >> >>
> >> >> Except that <va.h> would be in the "va.h" file, so are you fan of some
> >> >> #include_next magic?
> >> >
> >> > No magic needed, unless you used -I. on the compiler command line, and
> >> > FFmpeg doesn't do that.
> >>
> >> We are not talking about FFmpeg only, as vdpau<_render>.h is (going to
> >> be) public api.
> >> An application can do -Ilibavcodec -Ix11 and then include vdpau.
> >
> > You have missed an old discussion.  We have a lot of non-unique header
> > names already.  An example is png.h.  That's why we have changed FFmpeg
> > internally to always use full relative paths with e.g. libavcodec/
> > prefixes in the #include.
> >
> > It is the only way to use FFmpeg or libavcodec correctly.  Everything
> > else is bound to fail.
> 
> Still, there is no reason to change header from one form to more generic form
> only because YOU don't like it.

Nor is there a reason to follow your preferences.

Mans requested the change as well.  That's a 2:1 majority.  Now stop
flaming please.

Diego