[gst-devel] ffmpeg build setup

[Ronald Bultje]

Hi Thomas,

On Thu, 4 Mar 2004, Thomas Vander Stichele wrote:
> so, the current build setup for our gst-ffmpeg stuff is very wonky.

*nod*. For some reason, gst-ffmpeg's 'make patches' didn't do anything
here, so I only noticed that bug (and several related ones) after I
committed my stuff... The current CVS (checked with a clean copy of CVS)
is able to go through a clean ./autogen.sh && make or ./configure && make.
It is not very clean, however. Wonky sounds like a good term.

> I am unable to build it in the current state.

I committed my last stuff this morning (afternoon for you). Please try
again. I can definately confirm that this worked for me, unless I forgot
to commit something or my build wasn't going as it should.

Either way, I'd like to release the current state as 0.8.0 if it passes
make distcheck. We shouldn't try to redo all this in one or two days so
close to 0.8.0.

For those wondering, I didn't actually change that much. I was simply an
idiot for not doign it correctly. We've always used one patch, and used
patch ... < ... to apply it. I moved over to multiple separate patches,
and used a bash for loop to apply them. And I did that wrongly. Also,
later on, I wanted to apply the patches during configure instead of make,
and I did that wrongly again. So all this stuff is actually my fault, but
it's nothing big. :). No reason to revert this to its previous state
before releasing 0.8.0.

[.. ideas on gst-ffmpeg/ffmpeg ..]
Dave proposed to put ffmpeg locally, too. I guess it's something we'll
have to consider given what we want, given the unstability of mplayer CVS
and so on. I'm fine so far. I guess that putting a 'known state of files'
into gst-ffmpeg is ok, too. However, I feel that this will be a lot of
unnecessary work. I feel that mirroring their stuff in our CVS is OK, as
is putting some additional patches to it and checking this out into
gst-ffmpeg. However, you're also trying to make a set of rules for how we
could sync this upstream and so on; I feel that this is unnecessary.
People used to quilt will know how quilt works, and will rather use quilt
by hand, because quilt is really extremely powerful (I've gotten used to
it and I'm definately thankful to you for that; I don't want to lose
that). Therefore, adding new rules like make update, make push etc. seems
like unneeded to me. I'd rather see you give a pointer to the quilt
documentation in the ffmpeg local branch README.

We just make sure that the local CVS of ffmpeg will always contain:
* the ffmpeg source, plus all patches applied to it
* the quilt config file which says that all patches have been applied
* the actual patches

To sync with a newer upstream CVS version, we simply do:
* quilt pop -a
* ./update.sh <- script that checks out new ffmpeg into .
* quilt push -a <- and fix all errors
* quilt refresh
* ... commit

You don't need to build a whole system around this. I'm really very
comfortable with quilt and feel fine with using that. A small README
is enough, imo. Apart from that, your ideas seem fine, please go ahead!

Ronald