[MPlayer-cvslog] r35834 - trunk/configure

[Reimar Döffinger]

On 27 Jan 2013, at 15:30, Alexander Strasser <eclipse7 at gmx.net> wrote:
> 
> Diego Biurrun wrote:
> [...]
>> 
>> a) Patching libdvdcss in order to silence a harmless warning in another
>>   upstream library copy is not worth it.
> 
>  This is very disputable.
> 
>> b) libdvdcss will likely be changed to make all of this moot.
> 
>  Here you silently changed your opinion. Suddenly the fixing at the root
> stuff rightly vanished. If the CPP macro gets completely dropped in libdvdcss
> it is fixing the symptoms at the leaf. Your change in configure is just a
> hack because it is just favouring libdvdcss over lavf but not solving the
> inherent problem.
> 
> SUMMARY
> 
>  The imported copy was fixed months ago and worked fine. Your 2 commits just
> introduced a warning, without solving any problem.
> 
>  So to make it really short now:
> 
>  1. I will *not* continue playing your game here!
>     Thus I will *not* reply to your flames.
>  2. If you don't do it in 3 days I will revert both r35834 + r35835 myself.
>  3. Note that both changed #ifdef-lines in our libdvdcs copy will disappear
>     on the next synch to upstream if they decide to drop that macro completely.
>     So in that case r35834 + r35835 will be obsolete anyway.

I don't think this is really worth all the flames/discussion, though to be honest I think the best solution would probably be if both projects added prefixes to macros FF_ or DVDCSS_ for example.
Yes, it is a bit overkill since they are intended to be compiled separately as libraries but being able to copy in code still is nice, plus it excludes the (theoretical) case of some file wanting to define a macro with the same name as something configure now defines.
All that said, Alexander's suggestion has less of a risk that we will just forget to change it again after a dvdcss update, our custom hacks to dvdcss code are easier to find than a single #undef that should be a define in configure, even with -Wundef. Even though those custom changes are a bad idea.
Most of all I'd appreciate if we could avoid blowing this up even more.
> 

Thanks,
Reimar