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

Diego Biurrun diego at biurrun.de
Sun Sep 26 14:07:32 CEST 2010


On Sun, Sep 26, 2010 at 10:56:12AM +0200, Reimar Döffinger wrote:
> 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.

OK, it should indeed be possible to separate these steps.
I'll get to it right now.

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

Only those that we use exclusively through FFmpeg like openjpeg.  For
the others I'm passing the appropriate options to FFmpeg's configure.

Diego


More information about the MPlayer-dev-eng mailing list