From the ebuild: # mplayer ebuild uses "use foo || --disable-foo" to forcibly disable # compilation in almost every situation. The reason for this is # because if --enable is used, it will force the build of that option, # regardless of whether the dependency is available or not. The devmanual states that "Packages should not configure and link based upon what is available at compile time — any autodetection must be overridden." (http://devmanual.gentoo.org/general-concepts/use-flags/). Here, the ebuild is going out of its way to do the opposite. The ebuild is supposed to make sure the dependencies are available using DEPEND, so if things are working correctly this should be useless, although also harmless. In the case where things are not working correctly, however, this means I get a build missing features I requested. The current ebuild is basically ignoring all dependency errors. In my particular case, I got a binary that doesn't support displaying video and was very confused as to why a build on another machine with the same USE flags worked. It is very hard to debug the issue when all failures just produce a slightly different output from configure in the build log.
On testing, it turns out that mplayer has such a broken build system that half the --enable-foo options break the build, so my suggested change won't work. Details: mplayer has a hand-written configure script instead of using autoconf. One of the "features" of this script is skipping checks for --enabled options. Unfortunately, the checks are in charge of doing things like passing the correct libraries to the linker, so if you actually use flags like --enable-x11 mplayer omits needed libraries and fails to build.
