configure: Remove usage of memalign_hack in ffmpeg
[platform/upstream/gst-libav.git] / HACKING
diff --git a/HACKING b/HACKING
index d8e1f5a..da13515 100644 (file)
--- a/HACKING
+++ b/HACKING
@@ -19,19 +19,36 @@ of a given day.
 On head, the following things have been commited on top of this:
 * patches/, which is a directory with a set of patches, and a series file
   listing the order, as generated by quilt
-* .pc/, which is a tree of files that quilt uses to keep control of its state.
-  It contains a list of applied patches, and one directory per patch,
-  containing a tree of hardlinked files that were added to the patchset, and
-  a .pc file listing all files part of the patchset.
 * the result of having all these patches commited (ie, quilt push -a) to the
   ffmpeg tree.
 
-Both the actually patched CVS ffmpeg code as well as the .pc dir need to be
-commited to CVS so the state of quilt wrt. the source is in sync.
+The patched CVS ffmpeg code needs to be commited to CVS so that a checkout 
+gives the patched code
+
+The Quilt state .pc hidden directory must NOT be committed to CVS, because 
+having CVS subdirs inside it confuses the hell out of quilt and causes it to
+start storing diffs against CVS Entries files, and all hell breaks loose
+
+THE WARNING
+-----------
+
+***
+
+NEVER EVER commit stuff in gst-libs/ext/ffmpeg UNLESS your quilt stack is
+completely applied !
+This means, ALWAYS make sure quilt push -a has been run without problems.
+
+What's more, if you want to be on the safe side, make sure that you can
+unapply and reapply without problems, by running quilt pop -a then
+quilt push -a.
+
+The ONLY exception to this is when you're working on a branch to update
+the upstream source you're working with.
+
+***
 
 THE WAY
 -------
-
 - If you want to hack on our copy of the FFmpeg code, there are some basic
   rules you need to respect:
   - you need to use quilt.  If you don't use quilt, you can't hack on it.
@@ -42,50 +59,161 @@ THE WAY
     NO files listed with question mark.  If there are, somebody before you
     probably made a mistake.  To manage the state correctly, it is vital that
     none of the files are unknown to CVS.
-  - if you want to add a file to a patchset, you need to:
-    - be in the right patchset
-    - quilt add (file)
-    - cvs add .pc/(patchsetname)/(file)
-    - cvs commit .pc/(patchsetname) (to update the state of quilt in cvs)
-    - edit the file
-    - cvs add the file if it doesn't exist yet
-    - quilt refresh
-    - quilt push -a (This one is IMPORTANT, otherwise you'll have a huge diff)
-    - cvs commit
-  - if you want to add a patchset, you need to:
-    - go over the procedure with thomas to check it's correct
-    - decide where in the stack to put it.  ask for help if you don't know.
-    - go there in the patch stack (use quilt pop/push)
-    - quilt new (patchsetname).patch (don't forget .patch !)
-    - quilt add (files)
-    - cvs add .pc/(patchsetname) the whole tree
-    - cvs commit .pc/(patchsetname)
-    - quilt refresh
-    - quilt push -a
-    - cvs commit
-    - cvs diff (to check if any of the files are unknown to CVS; if they are,
-      you need to add them to CVS)
+
+FIRST TIME:
+  - The quilt state is kept in a hidden dir in the gst-libs/ext/ffmpeg dir, 
+    but this hidden dir can't be kept in CVS because it confuses patch. Hence
+    when you get a clean gst-ffmpeg checkout you have an ffmpeg tree with
+    patches applied, but no quilt metadata to modify it with.
+
+  - You need to create the quilt metadata in your checkout:
+    1) Unroll the quilt patches. In gst-libs/ext/ffmpeg, run:
+
+       tac patches/series | while read p; do patch -p1 -R < "patches/$p"; done
+
+    2) Now, push all the patches to quilt and it will apply them, but now with
+       the appropriate stored metadata:
+
+       quilt push -a
+
+- if you want to add a file to a patchset, you need to:
+  - be in the right patchset
+  - quilt add (file)
+  - cvs add .pc/(patchsetname)/(file)
+  - cvs commit .pc/(patchsetname) (to update the state of quilt in cvs)
+  - edit the file
+  - cvs add the file if it doesn't exist yet
+  - quilt refresh
+  - quilt push -a (This one is IMPORTANT, otherwise you'll have a huge diff)
+  - cvs commit
+
+- if you want to add a patchset, you need to:
+  - go over the procedure with thomas to check it's correct
+  - decide where in the stack to put it.  ask for help if you don't know.
+  - go there in the patch stack (use quilt pop/push)
+  - quilt new (patchsetname).patch (don't forget .patch !)
+  - quilt add (files)
+  - cvs add .pc/(patchsetname) the whole tree
+  - cvs commit .pc/(patchsetname)
+  - quilt refresh
+  - quilt push -a
+  - cvs commit
+  - cvs diff (to check if any of the files are unknown to CVS; if they are,
+    you need to add them to CVS)
+
+THE UPSTREAM
+------------
+At some points you want to update the upstream snapshot code to a newer date.
+This is easy if you follow the steps outlined here, but make sure to follow
+them correctly !
+
+- find a good CVS snapshot date for upstream, one that is known to work.
+  You're going to save yourself quite a bit of trouble if you verify this
+  first !
+- check it out to a local directory:
+  cvs -z9 -d:pserver:anonymous@mplayerhq.hu:/cvsroot/ffmpeg export -D '2004-04-11 23:00 GMT' ffmpeg
+- compile it and test it, make sure it works
+
+- in gst-ffmpeg/gst-libs/ext/ffmpeg:
+  - Pre-flight checks:
+    - first make sure you don't have local changes, all files are either in
+      CVS or in .cvsignore patch, the whole quilt stack is applied, and stuff
+      works.
+    - do a quilt pop -a and quilt push -a to verify everything is ok.
+
+  - Branch and rollback:
+    - tag HEAD with the branch root point:
+      cvs tag BRANCH-UPDATE-CVS-2004-04-11-23-00-ROOT
+    - branch:
+      cvs tag -b BRANCH-UPDATE-CVS-2004-04-11-23-00
+    - FIXME: lock cvs HEAD
+    - update local copy to branch:
+      cvs update -r BRANCH-UPDATE-CVS-2004-04-11-23-00
+    - peel off all patches:
+      quilt pop -a
+    - commit this
+      cvs commit
+    - check
+      cvs diff
+      you should only have ? for files that are generated somehow (binaries,
+      build files, ...)
+      you get warnings about cvs not finding files to diff that are in .pc
+      or generated by your patches
+
+  
+    - if you want, you can now compare this state of CVS (which should 
+      be last upstream CVS combined with your local unapplied quilt state)
+    - remember to NOT do cvs update from here on, since you popped your quilt
+      state all your added files that are also in CVS are not locally present.
+
+  - sync with upstream:
+    - in a temp dir, redo the export:
+      cd ..
+      mkdir tmp
+      cd tmp
+      cvs -z9 -d:pserver:anonymous@mplayerhq.hu:/cvsroot/ffmpeg export -D '2004-04-11 23:00 GMT' ffmpeg
+    - rsync it over the old ffmpeg tree
+      rsync -arv ffmpeg ..
+    - go back and commit this new snapshot
+      cd ../ffmpeg
+      cvs commit
+    - check if any new files got added that you should add to cvs
+      cvs diff
+      This will list a lot of local files missing, from your quilt state,
+      which you shouldn't worry about.  Just inspect all the ?'s and add
+      files to cvs that belong to upstream and should be in cvs.
+    - if everything's ok and commited, tag the state:
+      cvs tag UPSTREAM-CVS-2004-04-11-23-00
+
+  - reapply and fix quilt patches one by one
+    - try applying one
+      quilt push
+    - if that didn't work, inspect the patch and figure out how to fix it:
+      - if the patch got applied upstream completely, quilt push will tell
+        you the patch looks like a reverse patch.  In that case you can
+        remove the patch from your patches file (patches/series), and
+        remove the .pc/$(patchname) and patches/$(patchname).patch files from
+        cvs.
+      - if the patch conflicts somehow, you can force application with
+        quilt push -f
+        and then resolve all the rejects, and fix the patch completely.
+        Then refresh quilt state with 
+        quilt refresh
+     - when the patch is succesfully removed or reworked, commit current state
+       to CVS, then check again if nothing is missing using cvs diff, and
+       resolve problems/apply missing files from your quilt state/...
+
+  - after reapplying your complete quilt state, test locally if the complete
+    gst-ffmpeg module now works.  Compile and test.  Resolve all problems
+    (upstream errors, missing symbols, missing files, ...) until you have
+    a working module.  commit again.
+
+  - merge to head:
+    - update locally back to head
+      cvs update -A
+    - FIXME: unlock cvs HEAD
+    - merge from your branch
+      cvs update -j BRANCH-UPDATE-CVS-2004-04-11-23-00
+    - commit
+      cvs commit
+    - check for diffs
+      cvs diff
+    - tag merge point
+      cvs tag BRANCH-UPDATE-CVS-2004-04-11-23-00-MERGE
+    - add upstream date to "THE RECORDS" below
+
+  - get a drink
 
 THE PLUGIN
 ----------
 Some notes on how ffmpeg wrapping inside GStreamer currently works:
 * gstffmpeg{dec,enc,demux,mux}.c are wrappers for specific element types from
     their ffmpeg counterpart. If you want to wrap a new type of element in
-    ffmpeg (e.g. the URLProtocol things), then you'd need to write a new
     wrapper file.
-
-* gstffmpegcolorspace.c is a wrapper for one specific function in ffmpeg:
-    colorspace conversion. This works different from the previously mentioned
-    ones, and we'll come to that in the next item. If you want to wrap one
-    specific function, then that, too, belongs in a new wrapper file.
-
-* the important difference between all those is that the colorspace element
-    contains one element, so there is a 1<->1 mapping. This makes for a fairly
-    basic element implementation. gstffmpegcolorspace.c, therefore, doesn't
-    differ much from other colorspace elements. The ffmpeg element types,
-    however, define a whole *list* of elements (in GStreamer, each decoder etc.
-    needs to be its own element). We use a set of tricks for that to keep
-    coding simple: codec mapping and dynamic type creation.
+    The ffmpeg element types, define a whole *list* of elements (in 
+    GStreamer, each decoder etc. needs to be its own element). 
+    We use a set of tricks for that to keep coding simple: codec 
+    mapping and dynamic type creation.
 
 * ffmpeg uses CODEC_ID_* enumerations for their codecs. GStreamer uses caps,
     which consists of a mimetype and a defined set of properties. In ffmpeg,
@@ -130,3 +258,17 @@ Some notes on how ffmpeg wrapping inside GStreamer currently works:
 
 * there's lots of things that still need doing. See the TODO file for more
     information.
+
+THE RECORDS
+-----------
+- list of snapshots used:
+
+  CVS-2004-04-11-23-00
+  * other updates people didn't enter :)
+  CVS-2006-02-17-04-00
+
+THE REMINDERS
+-------------
+* the initial ffmpeg checkout was imported using:
+  - get CVS ffmpeg
+    cvs -z3 -d:pserver:anonymous@mplayerhq.hu:/cvsroot/ffmpeg co -D '2004-03-09 06:00 GMT' ffmpeg