[gst-devel] ffmpeg build setup

[Thomas V. S. <th...@ap...>]

Hi,

so, the current build setup for our gst-ffmpeg stuff is very wonky.  I
am unable to build it in the current state.  While this would look like
an easy problem, it is actually very hard, which I realized after trying
out quite a few setups before to fulfill the requirements we have.

I can't work on it right away, but I'll work on it soon.  I thought I'd
throw out some of my ideas here so you could check if I'm missing
something.

First of all, some requirements we want:

a) we want people to be able to checkout gst-ffmpeg from CVS, and build
it in the expected way, reliably and reproducably, with the most recent
code updates we have
b) we want to track the upstream code, but always work against a
well-defined state of that upstream code
c) we want to save our customisations as separate patches that we can
send upstream to be good community members
d) we want to make it easy for the people that actually do the ffmpeg
patching to work with

The hard part about the problem is that you need to figure out what the
right way is of saving the state of our customisations, and save that
state in only one form.

For example, it wouldn't work to check out CVS of ffmpeg, use quilt to
manage patchsets, and commit both the patchsets and the locally modified
cvs code, because then you put the same changes twice in CVS.  Another
developer checking out the module will then end up with the already
patched CVS code, and a bunch of patches that according to quilt aren't
applied yet.

Here's (roughly) what I propose and what I want to work on :

a) we import ffmpeg code from a given date on a vendor branch in our
CVS.  This is what we call "the upstream code" at any given point.

b) we set up our system so that gst-ffmpeg on HEAD (ie, the stuff people
will try to compile) contains our gst-ffmpeg code, together with a
completely patched set of code for ffmpeg.  Ie, the code in this module
will be the result of the vendor branch from a), patched with the
complete set of patches we are trying to maintain.

c) we set up a system for the ffmpeg module that is meant to maintain
the patchset.  I'm still forming ideas here on how to best do this part,
but basically it would be a module checked out by the people who
actually want to work on the patches to the upstream ffmpeg code.  They
would have to be slightly more careful on how they go about the code
(for example, to collaborate properly, you need to remove all your
patches locally before you cvs update, because the update will update
your patches that already are applied and you lose state information). 
I think this can however easily be done automatically by having a few
Makefile targets.

So, in this module, you would work like this:
"make update"
  -> would first do a consistency check, ie "do I have local
modifications not in my quilt patch set ?"
  -> then would pop all the patches, which results in the ffmpeg
checkout being the same as the upstream (vendor) branch
  -> runs cvs update

At this point, you have a checkout of clean upstream code, the latest
copy of the patchset we are working on together, plus your additional
local patches.

"make push" -> will make quilt push all patches again.  At this point,
you have your complete set of modifications locally again.  You can test
the updated version by running make again, which will compile
everything, you can test it out, ...

when you are happy with your local changes, that you have merged again
to your local set of patches, you are ready to commit your local
patchset to the repository.  First, add the new patches you have created
to cvs.  Then

"make commit" -> will again do a consistency check, pop all your patches
again (so that the ffmpeg tree is pristine again), and then commit your
current quilt patchset.

d) All we need now is some way of getting from the patchset to the
consumer branch of gst-ffmpeg.  That could also be automated; could be
as simple as "checkout vendor branch; checkout consumer branch; copy
over vendor branch to consumer branch; apply patches; commit"

e) of course, people who want to work on the gst-ffmpeg plugin (ie, not
the actual ffmpeg code, can still choose to use the consumer branch of
gst-ffmpeg completely because they do not touch the actual ffmpeg code.

How does that sound ? Does anyone see problems with this setup ?

Thomas