[MPlayer-dev-eng] configure --force-option (was --enable-gif)

[The Wanderer]

Ivan Kalvachev wrote:

> The Wanderer said:

>> Another possible issue (and keep in mind that I'm very far from
>> completely alert right now):
>> 
>> A while ago, someone presented a scenario which I did not fully
>> understand at the time but have since grasped, in which the current
>>  setup is a problem in a slightly different way. That person
>> regularly rebuilds MPlayer via an automated set of build scripts,
>> with the intention of *not* making it dependent on any but a
>> specific, known set of external libraries (this is a paraphase, I
>> don't remember the details). There are many things which he does
>> not want to include, so he passes a host of --disable flags at
>> compile time in the course of this automatic process. The problem
>> is that when a new feature is added to MPlayer, it is generally
>> made autodetected by default, meaning that since his automated
>> system doesn't know to provide a --disable flag for that particular
>> feature it will be added on the next automatic rebuild - and thus
>> he will have a dependency he doesn't want.
> 
> Cool. I like constructive feed back. Actually there is simple
> solution.

I don't see how this was "constructive", but okay...

>   --disable-all, enable-all, --enable-stable options.
> 
> As options rightmost (later) options override the previous. So one
> could have "--disable-all --enable-whatIneed" .

This works, and I think I like it, since it doesn't break the current
setup and it does add the functionality he needed. I could comfortably
go along with this.

> the whole default configure option may look this way:
> 
>   vo_xv=$default_option
>   vo_xvmc=$experimental_options

I don't understand what you're getting at here, but as I said I'm not
alert at the moment.

>> I can easily see how this is an undesirable result; I like the
>> current "--enable means enable" system,
> 
> humm? Now enable may mean "test" or may mean "force".

...no, it doesn't. Right now "--enable" means "force", in your
terminology; if there is any case in MPlayer's configure in which
--enable results in anything but what you call "force", I don't know
about it.

>> I don't want my computer assuming it knows better than I do, but I
>> can also see how it can cause people problems. I don't see any way
>> to fix those problems which does not involve making things not be
>> autodetected by default, but...
> 
> The usual argument I use is "If configure test fails do you think
> that the real code will compile?".

Irrelevant. If I want the compile to fail that way, that's my business,
and I don't want the computer assuming I made a mistake by telling it to
do things that way.

Yes, a --force option would still let me insist; the problem is that I
shouldn't *have* to 'insist', the thing should take me at my word the
first time.

(Note that the last time this came up, in the scenario I described
above, I was arguing in favour of keeping the current setup. Generally
speaking I still prefer it to anything in which --enable doesn't mean
"assume it's there and hang the consequences", but I also don't want to
leave actual problems unfixed; that does not mean I'm willing to change
the meaning of current terminology, but it does mean I'm willing to
accept a potential compromise.)

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

A government exists to serve its citizens, not to control them.