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

[Ivan Kalvachev]

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.

> mediaLib (support) is broken.  Somebody forcing it on will have to deal
> with fixing the code anyway, so changing one line in configure or
> config.mak should not put a great burden on them.
>
> > 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.

> > 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.