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

[Enrico Weigelt]

* Ivan Kalvachev <ivan at cacad.com> [2004-01-02 00:15:52 +0200]:

Hi,

<snip>
> I would suppose it is intuitive, as the rest of the world use it
> in that meaning. People don't care how the script have been created,
> they expect same things to work the same way ;)
ACK.

But I dont want to fight out which word is the best - at least each
case should have its option - and this should be consistent over the
whole package and all its (future) version.

<snip> 
> Well, there IS an inconsistency and a lot of confusion.
> As you may have missed my point in the last thread I repeat it.
> If the option is disabled by default, then --enable is enabling
> auto-detection. I give xvmc as example, but there are others.
This is not intuitive. 
If I say: "enable" I mean "enable it or die".
And if I say "try to enable" then I mean "try it if you can and give report".

Well, at this point I see some more situations:

a) enable evrything you like (comfortable but very uncontrollable)
b) enable feature XYZ (abort if test fails)
c) enable XYZ and ignore failing tests (if somehow possible)
d) no never ever enable XYZ (--disable-XYZ)

Normally we have two kind of situations:

a) quick build:

   a user wants just to build the package and automatically compile in
   support for evrything possible/useful, except some modifications
   (enable sth not enabled by default and explicitly disbable sth)
    
b) consitent build
 
   a user wants to know what features are supported, which dependencies
   the have and whether these the dependencies are fulfilled.
   with that information he selects exactly what he wants.
    

The difference of these two cases only becomes visible if you 

a) scope several versions which bring new features or change the 
   enable-default for several ones.
  
b) want to build for another host system (removing some "unneeded" 
   libs later could be seen as a special case of this)

> You see that a user cannot know what --enable will do for a
> particulat funtion unless he look in the script. Even more -
> if a function is changed from default disabled to
> default auto-detected, then the script body should also be changed.
ACK. 

This is what makes life hard for package maintainers.


<snip>
> > I think that there is a consensus among the developers that having a
> > possibility to force options avoiding autodetection is a good idea.
> 
> J/K. maybe they are too lazy to fix broken configure autodetection?
If we can agree on a consistent build system, I'll do this job.

But I dont want to invest time in things which just will be refused
by some fundamentalists ...


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact at metux.de
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/