[arch-dev-public] Mplayer in two separate packages
Thomas Bächler
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
> fribidi.
No, it is not. This is mplayer's brain-dead, stupid and completely
unlogical buildsystem.
This is how the logic works in autotools:
./configure
Feature foo is enabled if all necessary libraries are detected and
disabled otherwise.
./configure --enable-foo
Feature foo is always enabled, if some libraries are missing, configure
bails out with an error.
./configure --disable-foo
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:
./configure --enable-foo
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...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://www.archlinux.org/pipermail/arch-dev-public/attachments/20090424/2a331305/attachment-0001.pgp>
More information about the arch-dev-public
mailing list