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

[The Wanderer]

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
suggest...

-- 
       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.