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

[Diego Biurrun]

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.

> >> Another possible workaround is to make so check ignores the force and
> >> executes on "yes" and "auto". This of course could lead to problems
> >> when --with-mlib when used to force the path (the check could change
> >> the path to the default).
> >
> >Another possible workaround is to initialize the _mlibdir variable in
> >another place.  It does not have to happen in the check.
> 
> Not possible, look at the code.

Nonsense.  The line

  test -z "$_mlibdir" && _mlibdir=/opt/SUNWmlib

can be put anywhere.  It does not have to in the check.

> >> I don't think you can fix the above problems with less code.
> >
> >Maybe, maybe not.  But changing the semantics of one --enable option is
> >not the solution either.
> 
> I give you 100% clean solution and you reverse it because of some
> nonexistent abstract concept. Ignoring all possible troubles it could
> cause...
> I think you are just abusing your power.

Starting to flame again?

Your solution is not a solution, it's a hack.  We're talking about a
very broken lib on a little used operating system.  The breakage you
describe is a corner case at best.

And now *please* drop the issue, it is a huge waste of valuable time.
We have much more important things to do.

Diego