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

[Ivan Kalvachev]

The Wanderer said:
> Torinthiel wrote:
>
>> On Sun, Sep 05, 2004 at 03:29:09PM +0300, Ivan Kalvachev wrote:
>>
>>> I had kept silence for too long time. I think we should change this
>>> one.
>>>
>>> The Problem:
>>> --enable-option could force option or run test for it, depending on
>>> that is it enabled by default or not.
>>
>> If the test is not enabled by default it means that either:
>> 1. There is no test
>> 2. The test is somewhat broken
>> 3. The test is ok, but somebody forgot to make it default - bug.
>>
>>> This way we will have:
>>> --force-option - compile option without testing it availability.
>>>                  may break compile
>>> --enable-option - enable option if the test for it succeed. Same as
>>>                  --force if there is no test.
>>> --disable-option - don't try to compile and test this option.
>>
>> This is adding hundreds of do-nothing options. Almost all --enable-*
>> would do nothing, as autodetect is default whenever available. And
>> where it is not available then --enable would do what? OTOH, it would
>> be nice if, when i.e. there are several possible versions of
>> library/interface/whatever user could force selection one of these.
>> But neither the current system, nor your proposition permits this.
>> And THAT IMHO is what needs to be fixed.
>
> 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.

  --disable-all, enable-all, --enable-stable options.

As options rightmost (later) options override the previous. So one
could have "--disable-all --enable-whatIneed" .
the whole default configure option may look this way:

  vo_xv=$default_option
  vo_xvmc=$experimental_options



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

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

Wish You Best
   Ivan Kalvachev
  iive