[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