[arch-dev-public] Mplayer in two separate packages
thomas at archlinux.org
Fri Apr 24 09:31:48 EDT 2009
Hugo Doria schrieb:
> With --disable-fribidi (instead of --enable-fribidi) it's building fine, right?
> This seems to be related to fribidi and its a x86_64 specific problem.
> I am trying to find a solution but, for now, we could just disable
No, it is not. This is mplayer's brain-dead, stupid and completely
This is how the logic works in autotools:
Feature foo is enabled if all necessary libraries are detected and
Feature foo is always enabled, if some libraries are missing, configure
bails out with an error.
No tests are run for the feature foo, it is always disabled.
Now, the mplayer configure applies a different, badly documented and
brain-dead logic to the --enable-foo case:
Feature foo is always enabled and all tests for necessary libraries are
skipped. Furthermore, no -L, -l and -I flags are added to gcc that would
be necessary to compile feature foo. It is expected that the user adds
those flags to the Makefile himself (but it is completely undocumented
WHERE they should be added).
This means that if --enable-foo requires any additional compiler flags,
using it essentially breaks the whole build process. Some people on the
mplayer team seem to think this is a good idea, but it is actually
counter-intuitive and unhelpful for distribution packages.
If you want to actually --enable-fribidi, you can do so by NOT adding
any configure flag. If you are not building in a clean chroot, then you
have to add --disable-foo flags for all features you want to disable.
And there is no way to make sure a feature was actually enabled, unless
you carefully check the full output of configure.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 260 bytes
Desc: OpenPGP digital signature
More information about the arch-dev-public