[FFmpeg-devel] [PATCH] Coremake support - ffmpeg_nommx.patch (1/1) - ffmpeg-nommx.patch (1/1)

[Diego Biurrun]

On Mon, May 21, 2007 at 07:13:40PM +0200, Michael Niedermayer wrote:
> 
> On Mon, May 21, 2007 at 09:40:19AM -0400, Ronald S. Bultje wrote:
> > 
> > In article <20070520202630.GU16391 at MichaelsNB>,
> >  Michael Niedermayer <michaelni at gmx.at> wrote:
> > > On Sun, May 20, 2007 at 02:05:44PM -0400, Ronald S. Bultje wrote:
> > > > --- ffmpeg.orig/libavcodec/i386/fdct_mmx.c	2007-03-22 01:00:40.000000000 -0400
> > > > +++ ffmpeg/libavcodec/i386/fdct_mmx.c	2007-05-20 12:02:36.000000000 -0400
> > > > @@ -281,6 +281,13 @@
> > > >  #define C6 12299
> > > >  #define C7 6270
> > > >  TABLE_SSE2
> > > > +#undef C1
> > > > +#undef C2
> > > > +#undef C3
> > > > +#undef C4
> > > > +#undef C5
> > > > +#undef C6
> > > > +#undef C7
> > > >  }};
> > > 
> > > these dont seem to be #defined after the undef so what is this good for?
> > 
> > dsptest.c includes several .c files, each of which has these macros 
> > without undef'ing them the first time, i.e. assuming they're yet 
> > undeclared. This means if you include two such files, the second causes 
> > warnings because of redeclarations of all of those variables. undef'ing 
> > them at the end of the source file seems the right thing to do, at least 
> > in one of them. 
> 
> i disagree, the fact that dsptest.c #includes several random .c files
> is the problem, hacking the c files to make that possible is not a good
> solution
> 
> i guess i wouldnt be opposed to svn remove dsptest.c ...

Did it outlive its usefulness?  Then it should go ...

Diego