[MPlayer-cvslog] CVS: main configure,1.1197,1.1198

The Wanderer inverseparadox at comcast.net
Sat May 13 09:56:18 CEST 2006

Ivan Kalvachev wrote:

> 2006/5/12, Diego Biurrun CVS <syncmail at mplayerhq.hu>:
>> CVS change done by Diego Biurrun CVS
>> Update of /cvsroot/mplayer/main
>> In directory mail:/var2/tmp/cvs-serv1774
>> Modified Files:
>>         configure
>> Log Message:
>> --enable-mlib should behave like all other commandline parameters.
> Please, revert this.
> When --enable-mlib sets _mlib to "yes" the check will never be
> executed because it is etiher forced or disabled. This means that it
> could lead even to breaking compilation in case $MLIBHOME is not set
> and check cannot set the default path "/opt/SUNWmlib".

This is a valid objection, but IMO it is not by itself sufficient to
warrant using a different effective syntax for this option from the one
used (or, at least, "intended to be used" - and *very* strongly defended
on numerous past occasions) for every other option.

The only potentially acceptable solution I can see offhand would be to
create another option, in addition to '--enable', which would set the
variable to "auto" - to be provided *only* for options which are
disabled by default rather than autodetected by default (though it
should probably be ignored, rather than producing an error, for other
options). However, this would be a major change, which would alter the
sum total configure syntax and which I would expect to require
alterations to a number of other parts of configure than the one at
hand; it is not the sort of thing which should be done at all casually.

> Another possible workaround is to make so check ignores the force and
> executes on "yes" and "auto". This of course could lead to problems
> when --with-mlib when used to force the path (the check could change
> the path to the default).

I don't think that this is acceptable, since it makes it impossible to
say "do not run autodetection" (which, in effect, is what --enable in
MPlayer's configure is designed to do).

> I don't think you can fix the above problems with less code.

Beyond the potentially problematic above, I'm not sure what to

       The Wanderer is, however, glad you're actually arguing instead of 
merely flaming

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