[MPlayer-dev-eng] --enable-svga

[Gabucino]

Ivan Kalvachev wrote:
> > I'll commit in a few days" thing..  But let us not linger on this
> > subject.
> It was rejected (with flames).
And it will be rejected again and again.


> > But --enable for autodetection is not intuitive either.  Besides having a
> I would suppose it is intuitive, as the rest of the world use it
> in that meaning.
Rest of the world = broken fuck autoshit lusers


> People don't care how the script have been created, they expect same things
> to work the same way ;)
Don't forget world domination.


> If the option is disabled by default, then --enable is enabling
> auto-detection.
I'm missing the logic here. Reason: there is no logic.


> You see that a user cannot know what --enable will do for a
> particulat funtion unless he look in the script.
...so?


> Even more - if a function is changed from default disabled to default
> auto-detected, then the script body should also be changed. And this could
> adds bugs too;))
Next time you'll be promoting automake as the only uniform and glorious
way of MPlayer Development.


> Can you point an example where (e.g. gentoo) build script will need to
> force something?
Have you actually seen the gentoo build script? I did. About 20 pieces
of --enable options.


> Anyway, as I said I don't want more flames.
Sorry, but your idea is braindead..
What do we have now?
Ability to:
 - disable functionality
 - autodetect functionality
 - force functionality

Your offer:
 - disable functionality
 - autodetect functionality
 - autodetect functionality with "force" (lol. nonsense.)
 - force functionality (--really-enable-svga-please)
   (BTW automake lacks this... you can't even force anything. broken shit)

IMHO you shouldn't push this topic further.

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20040102/01ac7792/attachment.pgp>