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

[Torinthiel]

On Sun, Sep 05, 2004 at 08:26:57PM +0300, Ivan Kalvachev wrote:
> 
> Torinthiel said:
> > 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.
> 
> I think that there are options without test, that are enabled by default.
> Unfixed bugs should not be protected by our policy.)
> 
> [snip]
> 
> > 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
> 
> Are you working in microsoft? This is bug, not feature ;)

No, I'm just a lazy person. When I re./configure MPlayer at least once
a week, I want to know if anything in my setup has changed with as
little effort as possible. And having configure/build fail is little
effort on my side. Grepping/looking through log is much effort.

> It is much simplier to look at configure and see what have failed.
> On my system compiling mplayer takes quite some time. It is very annoying
> to understand that somebody had changed the behavioud of previously
> disabled function, after 30 minutes of compilation...
> 
> > '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
> 
> Are you talking about mplayer configure? At the end there is summary
> that list of all enabled and all disabled modules.
> You just have to watch at them ;)

Again. It's just some text, that shouldn't change, why should I read it?
I know, I'll soon be flamed than MPlayer is for people that know how to
handle it and so on. But I don't want to read through a list of drivers
that I need not remember just to check that MAYBE a recent update to the
system has screwed something.

> I like it.
> Even if configure doesn't fail, it would be very cool to have a list of
> "Explictly enabled but not available options" in the end of the
> configure script output.
> Only If I knew how to make it ;((

Pretty easy - the enabled/disabled lists are right now managed in such
way, that each test adds module name to one of two variables.
We could add that each test beforehand remembers if it was auto-yes, and
after checks 
test _wasrequest = yes -a _module = no &&
_requestednomodules="$_requestednomodules module"

> 
> Actually I would propose so:
> 
> option=auto-no; #when
> --force-*)  option=yes;
> --enable-*) option=auto-yes;
> --disable-*)option=no;

That's what I was proposing ;)
And I quite liked the idea of changing the default with one option.
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/bd336b47/attachment.pgp>