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

[The Wanderer]

Ivan Kalvachev wrote:

> 2006/5/13, Diego Biurrun <diego at biurrun.de>:
> 
>> On Sat, May 13, 2006 at 09:25:14PM +0300, Ivan Kalvachev wrote:

>>> Then how is user supposed to request auto detection if option is 
>>> disabled by default?
>> 
>> There is (currently) no way to request autodetection.
> 
> !

I'm not sure why you're surprised to learn this... *have* you in fact
been around for the past 'you people should change --enable to mean
"autodetect"' threads, or is my memory being unreliable again?

>>> Even if we assume that what you state is current semantics,
>> 
>> There is no "if" here.  Was the statement from Rich not clear
>> enough? Has the notion that you might actually be wrong ever
>> crossed your mind?
>> 
>>> then you must elaborate why it is better than the one I
>>> explained..
>> 
>> Because we do not second-guess the user decision.  Period.  Note
>> that this is orthogonal to the question whether we should have an
>> additional way of requesting autodetection.
> 
> First you don't give users choice to autodetect and then you don't
> let them second-guess.

No. First We don't give the user the option to autodetect (and note that
both he and (less importantly) I have said that it might be acceptable
to *add* a let-the-user-autodetect option), and then we don't say "well,
you said to turn it on, but we're going to autodetect instead" - because
doing that would be second-guessing the decision they made. The user
decision (to enable or disable a feature) is considered final; the most
we can ever do is fail out of configuration or compilation as a result.

The other point is that, in many although not all (or even necessarily
most) cases, things which are disabled by default are so because they
*have* no autodetection... usually because no one could come up with a
test which would work. I expect that that doesn't apply in this specific
instance, but since creating a new "autodetect even if you would
ordinarily not do so" option has been proposed, we would have to bring
up the question of how to handle such cases.

> The only result is that if user enables disabled-by-default option,
> there is quite big chance compilation to fail.

...your point?

If it's disabled by default, then there's generally a reason; with the
exception of things like the GUI, it probably doesn't work in the first
place. If the user wants to try to enable it, then they are taking the
burden of getting it set up to work onto themselves.

>>> Can you prove that? gui,xvmc,joystic ?
>> 
>> Both joystick and xvmc are unfinished as clearly stated in a
>> comment. Whether a user wants to build with or without GUI support
>> is not something that you can check for.
> 
> There are completely unrelated statements. I say that there checks
> performs checks when their state is "yes". This means that the
> current policy is the one I give as example.

You appear to be talking about the checks which are performed on the
condition of "variable != no" instead of "variable = auto". The latter
do seem to be quite prevalent, by proportion:

==
wanderer at pegasus:~/text/src/cvs/mplayer/main.pserver$ egrep 
"if.*=.?auto" configure | wc -l
102
wanderer at pegasus:~/text/src/cvs/mplayer/main.pserver$ egrep 
"if.*\!=.?no" configure | wc -l
28
==

They are, by and large, not supposed to be used, but they certainly do
exist.

However, a quick run down the list resulting from the latter grep does
not seem to support your thesis that the items checked with "!= no" are
those which are disabled by default; the only things I've found which
are initialized to "no" are _use_aton (which has no corresponding
configure option), _xvmc, _mp1e, and _opendivx (which may be a
complicated case, since it's part of the four-segment DivX check). Four
out of 28 doesn't seem like a guiding principle to me - especially not
when you consider that 65 other options which are initialized to "no" do
*not* have autodetection run.

That configure's current semantics are a little inconsistent appears
undeniable; however, this is almost certainly little more than a
holdover from less rigorous days which no one has gotten around to
fixing yet.

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