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

Torinthiel torinthiel at megapolis.pl
Sun Sep 5 15:07:10 CEST 2004


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.

I personally find --enable meaning enable, not try to detect, but
I agree that users are used to the senseless meaning. But there is also
other side of this. If --enable means force, then if we --enable something and
don't have the packages to do it, compilation will fail. And I find this
a feature - at least I will know that I'm lacking something. If it means
'try' then there is no way (other then manually checking configure.log)
to check than autodetect failed. Now, a common user passes --enable-foo
and then asks
'I've enabled foo in my build, but when I try to use it it's not there
I don't know what is happening, help me!!!'
I've found myself quite frequently in this situation, only I've first
searched my logs, then asked ;)

Some solution would be to have 4 mode for each option, lets name them
'yes' - force building this, set when you pass --force-*
'auto-yes' - autodetect, but fail ./configure if autodetecttion fails.
             set with sth like --enable-*, but I think it should get
			 other name
'auto-no' - autodetect. Enable if successful, do nothing if not. Default
'no' - totally disable this thing. --disable-*

> I appeal to you. Users don't know that we don't use autogen configure. They
> think it is normal configure.

<troll>Then they should learn checking if the build system is worth
something</troll>
Torinthiel

-- 
 Waclaw "Torinthiel" Schiller       GG#: 542916, 3073512
   torinthiel(at)megapolis(dot)pl
   gpg: B06901F1 fpr: FAA3 559F CAE9 34DE CDC8  7346 2B6E 39F2 B069 01F1
 "No classmates may be used during this examination"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20040905/350d0eba/attachment.pgp>


More information about the MPlayer-dev-eng mailing list