#33489: MPlayer @1.0rc4 - hidden dependencies ---------------------------+------------------------------------------------ Reporter: hans@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.4 Keywords: | Port: MPlayer ---------------------------+------------------------------------------------ Comment(by hans@…): Replying to [comment:2 ecronin@…]:
First, you probably should be looking at mplayer-devel or mplayer2. The MPlayer port is dead and should just be removed from ports since all it seems to do is cause confusion (it still builds most of the time which is why I'm hesitant to just replaced_by it in case someone really does think a 5 year old completely unsupported by upstream release candidate is better than a slightly less unsupported by upstream port with -devel in its name)
The only reason why I am using MPlayer @1.0rc4, out of those three, is that "port install mplayer" is the first that comes to mind. I believe it's in the names of the ports, which seem to suggest (to me anyway): {{{ mplayer = the regular stuff mplayer2 = new version, if you are adventurous mplayer-devel = bleeding edge, if you are more adventurous }}} If the ports were named "mplayer1", "mplayer", "mplayer1-devel" (instead of, respectively, "mplayer", "mplayer2", "mplayer-devel"), I believe people would be just using MPlayer2, because that would be what the obvious "port install mplayer" would do. Anyway, now that know of Mplayer2 (thank you), I will switch to that -- and take my bitching there.
Regarding that comment, the "let autodetect do its magic" part means that explicit {{{--enable-foo}}} or {{{--enable-foo=/opt/local}}} do not do the right thing with (ancient) mplayer's ./configure. To enable a feature you really do need to remove the --disable-foo flag but just let ./configure autodetect that foo is present, instead of adding --enable-foo like you do in normal autoconf'd programs. But the removing of --disable- foo only happens inside variant blocks where the necessary depends are added
Ugh, another reason to kill mplayer (1.0).
ffmpeg is odd since it used to always use a private internal copy and not link against the system version...
Another reason. I read Mplayer2 kicks the internal ffmpeg out, makes it a winner. Thanks again -- Ticket URL: <https://trac.macports.org/ticket/33489#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS