[MPlayer-cvslog] CVS: main configure,1.1197,1.1198

[Ivan Kalvachev]

2006/5/13, Diego Biurrun <diego at biurrun.de>:
> On Sat, May 13, 2006 at 04:21:50PM +0300, Ivan Kalvachev wrote:
> > 2006/5/13, Diego Biurrun <diego at biurrun.de>:
> > >How refreshing, your bringing forth technical arguments without
> > >resorting to flaming and insults.  This is most welcome..
> > >
> > >On Sat, May 13, 2006 at 10:09:57AM +0300, Ivan Kalvachev wrote:
> > >> 2006/5/12, Diego Biurrun CVS <syncmail at mplayerhq.hu>:
> > >> >
> > >> >Modified Files:
> > >> >        configure
> > >> >Log Message:
> > >> >--enable-mlib should behave like all other commandline parameters.
> > >>
> > >> Please, revert this.
> > >>
> > >> When --enable-mlib sets _mlib to "yes" the check will never be
> > >> executed because it is etiher forced or disabled. This means that it
> > >> could lead even to breaking compilation in case $MLIBHOME is not set
> > >> and check cannot set the default path "/opt/SUNWmlib".
> > >
> > >Having one --enable option behave different from the others is an
> > >unacceptable hack.
> >
> > It is not hack, it is the right solution. Actually gui, xvmc and
> > joystic are hacks.
>
> There are about 150 --enable parameters.  You want to change the
> semantics of one of them.  If this is not a hack, then we will have to
> find another word for it.  Whatever you wish to call it, it is not
> acceptable.

I told you I will change all of them, I just don't want to do it right
before the release.

I still don't understand why it is not acceptable. Because it doesn't
"look" like the others?
IT WORKS. That's all that matters. Call it whatever you want. It works BETTER.

Let's be pragmatic.