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

[Enrico Weigelt]

* The Wanderer <inverseparadox at comcast.net> [2003-12-30 00:17:38 -0500]:

<snip>
> This has been discussed fairly recently on (IIRC) this list, between
> Richard and someone whose name I forget who was advocating auto* and

I am _NOT_ advocating automake.

<snip>
> >a) --try-enable-foo
> >
> >    ==> to autodetection. (default)
> 
> Useless, because it *is* the default. If something isn't autodetected by
> default, then either no one's come up with a way to autodetect it or
> it's believed to not be worth compiling in; if the user disagrees,
> that's what --enable is for.
Okay, but what's when this is changed someday ?
Then the build parameters for a specific build will change ==> inconsistent.

For example there are many features enabled by default. You have to 
explicitly disable if you dont want them. Okay for one version, since 
the user can read the output and write his build script. 

But then comes a new version, which adds a new feature enabled by default.
He now _MUST_ reread the whole output of ./configure --help line per line
and check if there's a new feature and he really wants it!

And please dont argument "its not bad to have some unneeded features".
It _is_:

    a) adds unneeded bloat (why should I need vo_svga or sth like that
       if I never want to use it ?)

    b) it adds additional and _unneeded_ dependencies. If the user removes
       some lib, which support was compiled-in for w/o knowledge of the
       user, it will break up the mplayer installation. 
    
> >b) --enable-foo
> >
> >    ==> explicitly enable/disable some feature, but argue if
> >        something  seems to be missing/corruot
> 
> How can it tell if the thing is missing or corrupt? This would
> essentially be a slightly different form of autodetection, and hence
> seems to me to be a little redundant. 

Each feature has its depencies, i.e. a vo_svga wants libsvga in a specific
version or above. For autodetection we require some check method which 
says "yes, we have working libsvga" or "no we dont". This may be a small
shell script. Perhaps the check would also return "we have libsvga at
/usr/lib/ and include files in /usr/include/svga/".

As optimum I would like to have a simple machine readable description 
file which tells me:

* a list of supported features (i.e. w/ human readable description)
* a list of dependencies for each of the features (package, version, variants)
* a rule (i.e. configure-option) to enable this feature
* a rule for disabling the feature
* a rule for autodetecting (if present)
* the default (enabled|disabled)

It really doesnt matter for me whether it is the output of ./configure --help,
an other command or a textfile in the sourcetree - as long as it is 
consistent over all newer versions in (at least nearer) future.

If a new feature comes in, it is simply added to the list of features.
An automated build system then can generate the build command from it and
see if there's something new.

<snip>
> check configure.log, or if
this file is not machine readable, as well as the stdout of configure isnt.

<snip>
> >c) --force-enable-foo
> >
> >    ==> really enforce this feature - no matter what comes - go
> >        through  until the bitter end.
> 
> Already present as --enable.
Okay, but we're missing a way to asking configure for "can we enable foo ?".
This is only then done if the options is completely ommitted and is 
enabled by default (or autodetected).


<snip>

> Neither of these is particularly helpful.
This stuff perhaps isnt useful for _YOU_ and some other developers, as 
_YOU_ of course _KNOW_ what the current status is.

A package maintainer cannot know this, unless he inspects each version
in details. Of course for a high quality distro you have doublecheck
evrything before you declare something "stable", but if you wouldn't 
be so fundamentalistic, life could be so easy because machines are 
doing much of the work.

>From the view of a user, I just want to tell my build system / installer
"i wanna have mplayer w/ video out for X11, mpeg[1-4], bttv, realvideo,
DVD, 3dfx ... please install the the mplayer and the required libraries
and keep evryting up to date ... inform me if mplayer brings new features".

The required information could be modeled quite easily, but it requires
some _very little_ help from the developers, because package maintainance
would otherwise eat up much time.


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/