[MPlayer-dev-eng] [RFC] build from a single ffmpeg subdirectory

[Guillaume POIRIER]

Hello,

On Mon, Oct 13, 2008 at 11:17 PM, Diego Biurrun <diego at biurrun.de> wrote:
> I have had this in one of my local trees since forever and now finally
> sat it down to finish it...
>
> Here is an overhaul to the way we integrate FFmpeg with MPlayer.  It
> switches over from multiple subdirectories (and corresponding svn
> externals) to a single subdirectory for all of FFmpeg.  MPlayer's
> configure calls FFmpeg's configure and FFmpeg is built separately from
> the MPlayer build process.
>
> pros:
> - gets rid of a lot of duplicated code in the build system
> - no more MPlayer build failures after changes to FFmpeg's build system
> - needs just one svn:external, so it might work with git someday
>
> cons:
> - increases the size of the checkout as it pulls in unneeded parts of
>  FFmpeg


That's a very nice thing to do. One question though: how different
will it be to built MPlayer with that new scheme?
Currently, you just run ./configure on the root of MPlayer sources,
then make, and you get a working MPlayer binary, tuned to the CPU
you're using, and using every feature that your system allows to
build.

Will that situation change?

I see that you call ffmpeg's configure as follows:

+
+echo "Calling FFmpeg configure..."
+_ffmpeg_opts="--enable-gpl --enable-postproc --enable-swscale
--disable-vhook --disable-devices --disable-protocols
--disable-avfilter --disable-avfilter-lavf --disable-network
--disable-shared --disable-ffmpeg --disable-ffserver --disable-ffplay"

I doesn't look to me that you're passing some flags that would has
been passed to MPlayer's configure, or flags related to the processor
being used.
Have I missed smth?


In any case, I like the idea.

Guillaume
-- 
One should not give up hope on imbeciles. With a little training, you
can make them into soldiers.
 -- Pierre Desproges