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

The Wanderer inverseparadox at comcast.net
Sun Sep 5 17:16:15 CEST 2004


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.

I can easily see how this is an undesirable result; I like the current
"--enable means enable" system, 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 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.




More information about the MPlayer-dev-eng mailing list