[MPlayer-cvslog] r19456 - trunk/configure
The Wanderer
inverseparadox at comcast.net
Sun Aug 20 00:20:08 CEST 2006
Diego Biurrun wrote:
> On Sat, Aug 19, 2006 at 09:10:27PM +0200, iive wrote:
>
>> Modified:
>> trunk/configure
>>
>> Log:
>> Fix xv and xinerama force on --enable-*
>> The previous commit changed the conditions of check execution to mach Diego's semantics
>> (execute check only on 'auto'), but the 'else' case forces detection to 'no',
>> even if previous --enable had set it to 'auto'.
...huh?
'--enable-x(v|inerama)v' sets the appropriate variable to 'yes', not to
'auto'. The only way any variable gets set to 'auto' is if neither
--enable nor --disable is specified.
Was this just a semi-typo of "auto" for "yes", or is there something
else going on?
>> --- trunk/configure (original)
>> +++ trunk/configure Sat Aug 19 21:10:27 2006
>> @@ -3825,15 +3825,15 @@
>> else
>> + _xv=no
>> _def_xv='#undef HAVE_XV'
>> _novomodules="xv $_novomodules"
>> fi
>> @@ -3878,13 +3878,13 @@
>> else
>> + _xinerama=no
>> _def_xinerama='#undef HAVE_XINERAMA'
>> fi
>> echores "$_xinerama"
>
> Both of these are unnecessary, please remove them again. These else
> cases can only be reached if those variables are already set to no.
I don't think that's true. What about the case where _x11 is not 'yes'
and _xv is 'auto'? The Xv detection will not be run, _xv will not be
changed, and so it will still be 'auto' here; at a glance, the Xinerama
case is parallel.
Unless I'm less competent with shell code than I thought, which is
possible...
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Secrecy is the beginning of tyranny.
More information about the MPlayer-cvslog
mailing list