On 01/07/11 6:18 PM, Jan Stary wrote:
audio/sox
I will take care of audio/sox. In fact, I have an update for
audio/sox ready, as my main motivation for porting AMR was
to have AMR functionality in SoX.
Make sure to update the license marker in the Makefile to
GPLv3+.
graphics/ffmpeg
ffmpeg's configure recognizes
--enable-libopencore-amrnb
--enable-libopencore-amrwb
which default to [no] (but shouldn't ffmpeg's CONFIGURE_ARGS say
--disable-libopencore-amrnb
--disable-libopencore-amrwb
explicitly if it doesn't use it?).
No.
Currently, the output of ffmpeg's configure just says
libopencore-amrnb support no
libopencore-amrwb support no
even with opencore-amr installed and seems to ignore it
(unlike other stuff, whose --enable-* defaults to [autodetect])
That's fine.
multimedia/avidemux
multimedia/gstreamer-0.10 (plugins-bad and plugins-ugly)
These need to be built with opencore-amr already installed and checked as
to whether they need additional deps listing (WANTLIB/LIB_DEPENDS as usual,
but also LIB*_EXTRALIBS in ffmpeg). Ports depending on these also need to
be checked for additional WANTLIB.
What happens if some port's build chooses to use the installed
opencore-amr libs, but doesn't mention it in WANTLIB etc?
If its installed and a program happens to pick it up it could
result in a hidden dependency and thus binar(ies) that are
broken in the resulting package.
Would it be OK to explicitly --disable AMR in these ports
(before someone else chooses to correctly add the AMR
functionality to those ports), as above for ffmpeg?
Not necessary for FFmpeg, the rest will be done.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
