On Jul 01 17:01:41, Stuart Henderson wrote:
> On 2011-07-01, Giovanni Bechis <[email protected]> wrote:
> > On 07/01/11 15:39, David Coppa wrote:
> >> To anyone who wants to import it, you have my ok.
> >> 
> > Enable regression test as well, ok for me.
> 
> The following ports are very likely to pick this up:

What does 'pick it up' mean? If they want to use opencore-amr,
they will put it in their *_DEPENDS, edit their configure --options,
etc. They will not just 'pick it up' by accident, right?

> 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.


Index: Makefile
===================================================================
RCS file: /cvs/ports/audio/sox/Makefile,v
retrieving revision 1.49
diff -u -p -r1.49 Makefile
--- Makefile    15 Jun 2011 08:29:34 -0000      1.49
+++ Makefile    1 Jul 2011 22:13:31 -0000
@@ -3,7 +3,7 @@
 COMMENT=       Sound eXchange, the Swiss Army knife of audio manipulation
 
 DISTNAME=      sox-14.3.2
 
 CATEGORIES=    audio
 HOMEPAGE=      http://sox.sourceforge.net/
@@ -18,8 +18,10 @@ PERMIT_DISTFILES_FTP=        Yes
 MODULES=               converters/libiconv
 
 WANTLIB += c m ogg sndio z
-WANTLIB += vorbis vorbisenc vorbisfile FLAC magic
-WANTLIB += mad id3tag mp3lame wavpack png gsm
+WANTLIB += vorbis vorbisenc vorbisfile FLAC
+WANTLIB += opencore-amrnb opencore-amrwb
+WANTLIB += mad id3tag mp3lame wavpack
+WANTLIB += magic png gsm
 
 MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=sox/}
 
@@ -31,6 +33,7 @@ LIB_DEPENDS=  audio/libvorbis \
                audio/libid3tag \
                audio/lame \
                audio/wavpack \
+               audio/opencore-amr \
                graphics/png \
                audio/gsm
 
@@ -58,8 +61,8 @@ CONFIGURE_ARGS+=--without-sndfile \
                --with-mad \
                --with-id3tag \
                --with-lame \
-               --without-amrwb \
-               --without-amrnb \
+               --with-amrnb \
+               --with-amrwb \
                --with-wavpack \
                --with-png \
                --without-ladspa




> 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?).
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])


Index: Makefile
===================================================================
RCS file: /cvs/ports/graphics/ffmpeg/Makefile,v
retrieving revision 1.73
diff -u -p -r1.73 Makefile
--- Makefile    24 Jun 2011 11:16:21 -0000      1.73
+++ Makefile    1 Jul 2011 22:07:48 -0000
@@ -87,6 +87,8 @@ CONFIGURE_ARGS+= ${CONFIGURE_SHARED} \
                --disable-outdev=oss \
                --enable-gpl \
                --enable-libgsm \
+               --disable-libopencore-amrnb \
+               --disable-libopencore-amrwb \
                --enable-libmp3lame \
                --enable-libschroedinger \
                --enable-libspeex \


> 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?

> I know this is a bunch of work - but I am not OK with importing this
> until it's done as it risks breaking a lot of packages.

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?

        Jan

Reply via email to