[MPlayer-dev-eng] [RFC] all of FFmpeg as svn:external

[Reimar Döffinger]

On Sun, Sep 26, 2010 at 02:30:58AM +0200, Diego Biurrun wrote:
> On Mon, Jul 12, 2010 at 11:39:36AM +0200, Diego Biurrun wrote:
> > I have been working on changing the build system to use all of FFmpeg
> > as a single svn:external instead of multiple svn:externals for each
> > library that we use.
> > 
> > This avoids duplicating much of the FFmpeg build system and indeed the
> > diffstat is quite attractive:
> > 
> >  Makefile   |   47 --
> >  common.mak |  109 ------
> >  configure  |  995 ++-----------------------------------------------------------
> >  subdir.mak |  101 ------
> >  4 files changed, 48 insertions(+), 1204 deletions(-)
> 
> OK, this has been cooking for long enough, here is an updated version.
> The diffstat is looking even more charming:
> 
>  Makefile   |   52 ---
>  common.mak |  113 ------
>  configure  | 1043 ++-----------------------------------------------------------
>  subdir.mak |  101 -----
>  4 files changed, 65 insertions(+), 1244 deletions(-)
> 
> One issue I'm still aware of is that we need to require the same version
> of libmp3lame as FFmpeg or duplicate the check in our configure again.
> Otherwise MPlayer's configure can go through and FFmpeg's subsequently
> fails.  Upgrading the libmp3lame requirements seems like the cleanest
> and simplest solution.
> 
> Since this is now working for me, I would like to soon commit it, so it
> gets widespread testing.
> 
> All sorts of comments very welcome.

I'd _strongly_ prefer it if this wasn't all done in one go.
In particular, I'd prefer if just moving to a full ffmpeg svn:external
first, and then move to using FFmpeg configure only in a separate step.
Particularly since that second step in its current form without any documentation
will require anyone who used those options to spend hours to figure out
what the corresponding FFmpeg option is.
There is also the much larger issue that by using FFmpeg configure anyone
not specifying any options will lose support of mp3lame, vorbis, openjpeg,
x264, ..., that really is not user-friendly at all.