[MPlayer-dev-eng] [PATCH] prevent lavc-->xvid compilation for xvid < 1.1

[Ivan Kalvachev]

2006/3/20, Corey Hickey <bugfood-ml at fatooh.org>:
> On Sun, March 19, 2006 15:01, Ivan Kalvachev wrote:
> >> libavcodec/xvid_rc.c doesn't compile unless xvid is version 1.1. The
> >> attached patch makes configure check for version 1.1 (and,
> >> presumably,
> >> higher) and only enable libavcodec xvid support if the test passes.
> >>
> >> This should fix a bug reported by Jeon Hyeong-yong on
> >> mplayer-cygwin.
> >>
> >> Shall I apply it? I'll do so after work tommorrow if I don't see any
> >> objections, or sooner if there's any support.
> >
> > I would prefer more meaningfull name instread of xvid4_1_1, e.g.
> > lavc_xvid, just like the new def_ .
>
> Since it was a check for version 1.1, I wanted to make the name
> meaningful for anything in the future that might depend on version 1.1
> but not necessarily have anything to do with lavc. I agree, though,
> the name is a bit clunky, and if you want to suggest something better
> (or reaffirm your preference for lavc_xvid), I don't have a strong
> opinion either way.

Ok, then we have deal. (jfy there will be xvid1.2, xvid1.3,xvid2.0,
and all these version may give positive for xvid4_1_1 - very
confusing).

>
> > BTW doesn't xvid have some kind of verion numbers?
>
> There appear to be macros defined in xvid.h. From my xvid cvs tree:
> #define XVID_VERSION             XVID_MAKE_VERSION(1,2,-127)
> #define XVID_MAKE_VERSION(a,b,c) ((((a)&0xff)<<16) | (((b)&0xff)<<8) |
> ((c)&0xff))
>
> I suppose I could use them -- it just seems more simple to check for
> the API additions at the moment. Perhaps I could combine the xvid
> tests using that macro; it didn't exist before 1.0, but in that case a
> test compilation failure would indicate xvid3.

Yeh, bad idea. Keep the test as it is.