[MPlayer-cvslog] r33790 - in trunk: configure libmpcodecs/vf_yadif.c

[Diego Biurrun]

On Sun, Jul 03, 2011 at 12:22:02AM +0200, Reimar Döffinger wrote:
> On 2 Jul 2011, at 21:03, Diego Biurrun <diego at biurrun.de> wrote:
> > On Sat, Jul 02, 2011 at 05:15:40PM +0200, Reimar Döffinger wrote:
> >> On 2 Jul 2011, at 14:07, Diego Biurrun <diego at biurrun.de> wrote:
> >>> On Fri, Jul 01, 2011 at 11:57:28PM +0300, Ivan Kalvachev wrote:
> >>>> On 7/1/11, diego <subversion at mplayerhq.hu> wrote:
> >>>>> 
> >>>>> Log:
> >>>>> configure: Drop check for compiler support of named assembler arguments.
> >>>>> 
> >>>>> This was done to accomodate legacy compilers that are no longer supported.
> >>>> 
> >>>> Exactly what compilers do you have in mind and who exactly decided
> >>>> they are not longer supported?
> >>>> 
> >>>> This commind, r33770 and r33786, It looks like you are intentionally
> >>>> trying to cripple older compilers support.
> >>> 
> >>> False, I am doing no such thing.  I suggest you grab one of those older
> >>> compilers (good luck getting them built in the first place) and see for
> >>> yourself, like I did.
> >> 
> >> Huh? Before FFmpeg removed support it we through fine with compilation
> >> except for one actual FFmpeg bug which is fixed (AFAIK not yet fixed
> >> in Libav).
> > 
> > Not sure I understand you correctly, this sentence is hard to parse.
> 
> The short version: it compiled fine for FFmpeg IIRC a few days ago.

... and another few days later this is no longer the case ...

> >> And there's no need to compile, just install the recent Haiku alpha,
> >> gcc 2.95 is still the default compiler. So you'll have to use a few
> >> more words if you want us to see anything for ourselves. Removing
> >> that stuff when you are aware that some other developers just started
> >> playing a bit with gcc 2.95 certainly isn't the height of politeness.
> > 
> > I have gcc 2.95, it can compile neither FFmpeg nor Libav.
>
> First, you claimed it is unsupported, I don't think you can know that
> for certain for FFmpeg yet.

I compile-tested and looked at the git log, that's about as much certainty
as one could expect to receive, don't you agree?

> Then, MPlayer can be compiled against a system version of FFmpeg.
> This is even somewhat relevant since MPlayer contains and uses C++
> code, in contrast to FFmpeg (as far as I know), so requiring 2.95 for
> MPlayer is more problematic than for FFmpeg. Not that I know if anyone
> actually uses/relies on a live555 version compiled with gcc 2.95...

Given how crappy 2.95 was for C++, I think this can safely be ruled out.

> Never tested how far you get with not compiling against FFmpeg at all
> (only libavutil), it was supposed to be supported once, which should
> also still compile fine.

You need libavutil in the source tree, so this is debatable.

> Yes, this is all a huge waste of time, but seriously if you don't
> see a bit of a lack of politeness in removing that code "in all
> haste" because it doesn't compile (for now and AFAICT not in all
> configurations), without discussion with anyone even though you are
> aware others used it shortly before, and then answer with a fairly
> arrogant "try yourself" (even though directed at someone else) then IMO
> you might have caught something from Michael...

Hey, I was talking with Ivan - what do you expect? ;)

I suggest you decide what you really want over at FFmpeg.  It seems to
go back and forth on a daily basis.

> From a more practical point, the way you removed the support means it
> ends up with obscure compile errors even though we already have all the
> checks in configure to do this more properly (and possibly even select a
> supported version automatically).

You want to reject some compilers in configure up front?  Go right ahead.

Diego