Added debian extra dependency packages.

Signed-off-by: Michele Calgaro <[email protected]>

1 files changed, 720 insertions, 0 deletions

diff --git a/debian/mp4v2/mp4v2-2.0.0~dfsg0/doc/BuildRepository.txt b/debian/mp4v2/mp4v2-2.0.0~dfsg0/doc/BuildRepository.txt
new file mode 100644
index 00000000..aab40aa8
--- /dev/null
+++ b/debian/mp4v2/mp4v2-2.0.0~dfsg0/doc/BuildRepository.txt
@@ -0,0 +1,720 @@
+MP4v2 2.0.0 Building the Repository
+***********************************
+
+Table of Contents
+*****************
+
+1 Overview
+2 Introduction
+3 Quickstart
+4 Build Process
+  4.1 Checkout Sources
+  4.2 Boostrap (Autotools)
+  4.3 Configure
+  4.4 Build
+  4.5 Install
+  4.6 Create Distribution
+  4.7 Build Documentation
+  4.8 Post Site and API Documentation to project website.
+5 Platform Notes
+  5.1 Mac OS X
+    5.1.1 Default Binaries
+    5.1.2 Release Binaries
+    5.1.3 Developer Binaries
+    5.1.4 Universal Binaries - all architectures
+    5.1.5 Universal Binaries - selected architectures
+  5.2 Linux
+    5.2.1 Default Binaries
+    5.2.2 Release Binaries
+    5.2.3 Developer Binaries
+    5.2.4 Bi-arch compilation
+  5.3 FreeBSD
+    5.3.1 Default Binaries
+    5.3.2 Release Binaries
+    5.3.3 Developer Binaries
+    5.3.4 Bi-arch compilation
+  5.4 Solaris
+    5.4.1 Default Binaries
+    5.4.2 Release Binaries
+    5.4.3 Developer Binaries
+    5.4.4 Bi-arch compilation
+  5.5 Cygwin
+    5.5.1 Default Binaries
+    5.5.2 Release Binaries
+    5.5.3 Developer Binaries
+  5.6 Windows
+
+
+1 Overview
+**********
+
+The documented and supported method to build MP4v2 uses the GNU build
+system (also known as the Autotools). You must first obtain the sources
+by either downloading and extracting the source-distribution bundle or
+working directly MP4v2's Subversion repository. We have build documents
+for both methods, but unless you are a member of the MP4v2 project, you
+are strongly encouraged to use the source-distribution method.
+
+On other supported platforms which lack Autotools we provide an
+alternative method for building the software. Please see the
+appropriate platform section.
+
+2 Introduction
+**************
+
+This document describes the recommended process to build MP4v2 from the
+repository. This process is a superset of the process to build from a
+source-distribution bundle.  If you are interested in building from a
+source-distribution bundle then this document is not for you.
+
+3 Quickstart
+************
+
+This chapter is for the impatient or those just looking for a quick
+summary of all the commands used in a typical build. You may skip this
+summary and jump to *note Build Process::.
+
+     svn checkout https://mp4v2.googlecode.com/svn/releases/2.0.0 mp4v2
+     cd mp4v2
+     autoreconf -fiv
+     rm -fr build/
+     mkdir build/
+     cd build/
+     ../configure
+     make
+     make install
+     make install-man
+     make dist
+
+4 Build Process
+***************
+
+4.1 Checkout Sources
+====================
+
+Checkout sources from the project's Subversion repository.
+
+Sources are checked out from either the trunk, release or a branch.
+This document was generated from one of those, and for example
+purposes, we will use exactly the same URL which used to create the
+distribution which contains this document.
+
+If you are a project member, then you may add the appropriate
+login/password information as needed.
+
+     svn checkout https://mp4v2.googlecode.com/svn/releases/2.0.0 mp4v2
+     cd mp4v2
+
+It is recommended to use Subversion 1.5.0 or higher.  Lower versions
+might work.
+
+4.2 Boostrap (Autotools)
+========================
+
+The following command causes forces Autotools to regenerate all files
+and install helper scripts needed at configure-time and to regenerate
+all files.
+
+     autoreconf -fiv
+
+If you are a project member and preparing for a release, it is
+important to note that the versions of Autotools available in your path
+will directly effect files added to the bundle. At the time of writing,
+the following versions of Autotools are recommended; in some cases a
+minimum is hard-coded and warnings will be issued if in violation:
+
+   * GNU autoconf 2.61 or higher (lower versions might work)
+
+   * GNU automake 1.10 or higher (lower versions might work)
+
+   * GNU libtool 1.5.26 or higher (lower versions might work)
+
+4.3 Configure
+=============
+
+The following command configures the project for a build.  It is highly
+recommended that you invoke configure from an empty directory.
+
+     rm -fr build/
+     mkdir build/
+     cd build/
+     ../configure
+
+Please see `INSTALL' for details on configure usage, and standard
+options. Additionally, the following custom options have been added to
+`configure':
+
+`--disable-debug'
+     Do not generate debug information.  Do not direct compiler to
+     generate debugging information. By default the compiler will
+     generate debug information if the platform supports it.
+
+`--disable-optimize'
+     Do not optimize. Do not direct compiler to optimize code. By
+     default compiler optimization is enabled if the platform supports
+     it.
+
+`--disable-fvisibility'
+     Do not set default ELF symbol visibility. By default configure
+     attempts to detect if the compiler supports this feature. However
+     on some platforms detecting incompatibilty of this feature might
+     not be accurate in which case this option should be given.
+
+`--disable-gch'
+     By default certain platforms are marked to use GCC precompiled
+     headers. Generally this greatly decrease build times but may
+     require more diligence for iterative development; that is to say
+     dependencies may not properly be tracked and more frequent `make
+     clean' may be required when headers are changed. Use this option
+     to disable GCC precompiled headers.
+
+`--disable-largefile'
+     On some 32-bit platforms or configurations it might be desirable
+     to build without largefile (LFS) support. By default configure
+     attempts to detect formal LFS support and enables it if found.
+
+`--disable-util'
+     Do not build/install utilities. This is convenience option for
+     users who desire to skip building the utilities (eg. command-line
+     executables) which are enabled by default.
+
+`--enable-bi=ARCH'
+     On bi-arch capable platforms it is possible to generate 32 or 64
+     bit code. This is supported by adding arguments `-m32' or `-m64',
+     respectively, when compiling or linking. Use this option to
+     override the platform-specific default.
+
+`--enable-ub[=ARCHS]'
+     On OSX systems it is possible to generate universal binaries. This
+     is supported by adding one or more argument patterns `-arch ARCH'
+     when compiling or linking. Use this option to either target an
+     architecture different from the platform default, or to produce
+     universal binaries.
+
+`--enable-dependency-tracking'
+     Enable automatic dependency tracking for include-files. By default
+     this feature is disabled.
+
+
+4.4 Build
+=========
+
+The following command will build MP4v2.
+
+     make
+
+On some platforms `make' refers to a BSD-flavor of make which is not
+compatible with this project. Check if `gmake' is installed, and if it
+is, substitute `gmake' wherever you may see `make' in this document.
+Otherwise you will need to install GNU make package version 3.81 or
+higher. Lower versions might work.
+
+4.5 Install
+===========
+
+The following command will install MP4v2.
+
+     make install
+     make install-man
+
+4.6 Create Distribution
+=======================
+
+The following command will create a MP4v2 source distribution. It is
+during this step that shipped documentation is generated.
+
+     make dist
+
+This step in the build process introduces additional requirements to
+the host system. While most of the following utilities are generally
+available, `help2man' is used to generate man-pages; however if this
+command is not available the man-pages will be empty. This is
+acceptable for non-release builds but for full quality builds this
+command is required.
+
+   * GNU help2man 1.36 or higher (lower versions should work)
+
+   * GNU tar 1.15.1 or higher (lower versions should work)
+
+   * GNU gzip 1.3.10 or higher (lower versions should work)
+
+   * bzip2 1.0.4 or higher (lower versions should work)
+
+   * Info-ZIP zip 2.32 or higher (lower versions should work)
+
+4.7 Build Documentation
+=======================
+
+This step in the build process introduces some significant requirements
+to the host system:
+
+   * GNU texinfo 4.8 or higher (lower versions should work)
+
+   * Doxygen 1.5.7 or higher (lower versions should work)
+
+Documentation that is shipped with source-distribution is generated as
+part of the *note Build Process:: step. This section documents builds
+all of the supported methods to build documentation. There are three
+kinds of documentation in this project; man-pages, articles and API.
+Documentation must be build from the repository.
+
+Man-pages are automatically generated for command-line utilities by
+using `html2man' which invokes standard options `--help' and
+`--version' and gleans the information, generating a man-page in nroff
+script. Note that the utilities will first be built as they are
+depdendencies of man-page generation.
+
+Artcles are usually hand-written and authored in Texinfo format which
+permits macro-expansions, simple formatting and conversion to several
+popular formats using the GNU `makeinfo'. A Texinfo manual
+(http://www.gnu.org/software/texinfo) is available.
+
+API is documented inline to C and C++ source files, usually headers
+using Doxygen comment-formatting. Doxygen is then used to post-process
+these files and generate documentation in various formats. A Doxygen
+manual is available at it's main site (http://www.doxygen.org) .
+
+The project's goal is to document as thoroughly as possible the public
+API in MP4v2. Since we never have enough time to document everything,
+we try to set some priorities in this regard. Generally the public API
+is the highest priority to document. Next most important is probably
+underlying utility code which is shared by many developers; for example
+libplatform.
+
+If you need examples of how to document C-compatible source see
+`include/mp4v2/mp4v2.h' and for C++-only source see
+`libplatform/io/File.h' .
+
+The following table describes the various make targets available for
+building docs. Note you must first have completed the *note Configure::
+step.
+
+`make man'
+     Generate man-pages for command-line utilities.
+
+`make html'
+     Generate articles in HTML format from `texi' files.
+
+`make txt'
+     Generate articles in plaintext format from `texi' files.
+
+`make wiki'
+     Generate articles in Google Code Wiki format from `texi' files.
+
+`make xml'
+     Generate articles in (Texinfo) XML format from `texi' files.
+
+`make api'
+     Generate API in HTML format from header files.
+
+`make articles'
+     Convenience; the equivalent of `make html txt wiki xml' .
+
+`make doc'
+     Convenience; the equivalent of `make man articles api' .
+
+
+And finally all of the document targets have a corresponding clean
+target which cleans up generated files. Simply prefix as follows:
+
+     make manclean
+     make htmlclean
+     make txtclean
+     make wikiclean
+     make xmlclean
+     make apiclean
+     make articlesclean
+     make docclean
+
+4.8 Post Site and API Documentation to project website.
+=======================================================
+
+This step is for project maintainers and can be used to update Site and
+API documentation. The following components are updated:
+
+   * Featured Wiki article: BuildRepository
+
+   * Featured Wiki article: BuildSource
+
+   * MP4v2 (trunk) docs (includes Release Notes and other articles, and
+     API docs).
+
+This procedure may only be run from a *nix platform and has only been
+tested on Mac OS X.
+
+`make google.clean'
+     Clean any local working copy of google changeset.
+
+`make google.post'
+     Generate required docs, sparse-checkout google tree, remove files
+     which are no longer generated, add new files which are generated,
+     and update existing files.
+
+`svn ci -m "-refreshed GoogleCode site+api docs." google/.'
+     Check-in changes. This might take several minutes, especially if
+     your upstream bandwidth is limited.
+
+
+5 Platform Notes
+****************
+
+MP4v2 builds on many unix-style platforms, also commonly referred to as
+posix-style systems. Building on Mac OS X, Linux, FreeBSD, Solaris,
+Cygwin, Windows are known to work.
+
+Similar platforms should also work. Please see the following platform
+specific notes for instructions on commonly used options for various
+platforms.
+
+5.1 Mac OS X
+============
+
+Building on Mac OS X is well supported as it is used by maintainers of
+this project. The following are the recommended specifications for this
+platform; but is not necessarily the only configuration that is
+possible:
+
+   * Mac Intel hardware
+
+   * Mac OS X 10.5.7
+
+   * Xcode-3.1.2
+
+   * gcc 4.0.1 (Apple Inc. build 5493)
+
+   * gcc 4.2.1 (Apple Inc. build 5570)
+
+     Note: It is recommended to use the platform distribution's bundled
+     compiler for maximum C++ compatibility. If you build with a custom
+     compiler it will likely introduce non-standard runtime
+     requirements for your users. There are of course many valid
+     reasons to build with unbundled compilers, but be aware that is
+     generally unsupported and left as an exercise to the reader.
+
+5.1.1 Default Binaries
+----------------------
+
+The preferred method to produce default binaries is to run configure
+without any options which will compile with debug+optimize and produce
+static+shared libraries and dynamic executables.
+
+     ../configure
+
+5.1.2 Release Binaries
+----------------------
+
+The preferred method to produce binaries suitable for releases, (ie.
+which does not contain debug information) is to pass the following to
+configure:
+
+     ../configure --disable-debug
+
+5.1.3 Developer Binaries
+------------------------
+
+The preferred method to produce binaries suitable for development is to
+pass the following to configure.  Default Binaries will work, however
+for the best debugging experience we recommend no optimize and no
+static libraries.
+
+     ../configure --disable-optimize --disable-static
+
+5.1.4 Universal Binaries - all architectures
+--------------------------------------------
+
+The preferred method to produce universal binaries for all supported
+architectures is to pass the following option to configure. As of this
+writing, architectures { i386, x86_64, ppc, ppc64 } are built.
+
+     ../configure --enable-ub
+
+5.1.5 Universal Binaries - selected architectures
+-------------------------------------------------
+
+The preferred method to produce universal binaries for selected
+architectures is to specify a comma-delimited list specifying the
+desired architecture identifiers. Passing the following option will
+produce universal binaries for architectures { i386, x86_64 }.
+
+     ../configure --enable-ub=i386,x86_64
+
+5.2 Linux
+=========
+
+Building on Linux is well supported as it is used by maintainers of
+this project. The following are the recommended specifications for this
+platform; but is not necessarily the only configuration that is
+possible:
+
+   * Intel 32-bit or 64-bit hardware
+
+   * Fedora 10, gcc 4.3.2
+
+   * gcc 3.4.0 or higher is reported to work
+
+     Note: It is recommended to use the platform distribution's bundled
+     compiler for maximum C++ compatibility. If you build with a custom
+     compiler it will likely introduce non-standard runtime
+     requirements for your users. There are of course many valid
+     reasons to build with unbundled compilers, but be aware that is
+     generally unsupported and left as an exercise to the reader.
+
+5.2.1 Default Binaries
+----------------------
+
+The preferred method to produce default binaries is to run configure
+without any options which will compile with debug+optimize and produce
+static+shared libraries and dynamic executables.
+
+     ../configure
+
+5.2.2 Release Binaries
+----------------------
+
+The preferred method to produce binaries suitable for releases, (ie.
+which does not contain debug information) is to pass the following to
+configure:
+
+     ../configure --disable-debug
+
+5.2.3 Developer Binaries
+------------------------
+
+The preferred method to produce binaries suitable for development is to
+pass the following to configure.  Default Binaries will work, however
+for the best debugging experience we recommend no optimize and no
+static libraries.
+
+     ../configure --disable-optimize --disable-static
+
+5.2.4 Bi-arch compilation
+-------------------------
+
+The preferred method to produce a bi-arch binary is to specify the
+target (eg. 32-bit) with the following option to configure. This
+example will produce a 32-bit binary if compiling on a platform which
+defaults to producing 64-bit binaries. The inverse is also possible.
+
+     ../configure --enable-bi=32
+
+     Warning: Currently bi-arch cross-compilation is not supported due
+     to a bug with libtool which fails miserably during linking.
+
+5.3 FreeBSD
+===========
+
+Building on FreeBSD is supported. The following are the recommended
+specifications for this platform; but is not necessarily the only
+configuration that is possible:
+
+   * Intel 32-bit or 64-bit hardware
+
+   * FreeBSD 7.0 Release, gcc 4.2.1
+
+   * gcc 3.4.0 or higher is reported to work
+
+     Note: It is recommended to use the platform distribution's bundled
+     compiler for maximum C++ compatibility. If you build with a custom
+     compiler it will likely introduce non-standard runtime
+     requirements for your users. There are of course many valid
+     reasons to build with unbundled compilers, but be aware that is
+     generally unsupported and left as an exercise to the reader.
+
+5.3.1 Default Binaries
+----------------------
+
+The preferred method to produce default binaries is to run configure
+without any options which will compile with debug+optimize and produce
+static+shared libraries and dynamic executables.
+
+     ../configure
+
+5.3.2 Release Binaries
+----------------------
+
+The preferred method to produce binaries suitable for releases, (ie.
+which does not contain debug information) is to pass the following to
+configure:
+
+     ../configure --disable-debug
+
+5.3.3 Developer Binaries
+------------------------
+
+The preferred method to produce binaries suitable for development is to
+pass the following to configure.  Default Binaries will work, however
+for the best debugging experience we recommend no optimize and no
+static libraries.
+
+     ../configure --disable-optimize --disable-static
+
+5.3.4 Bi-arch compilation
+-------------------------
+
+The preferred method to produce a bi-arch binary is to specify the
+target (eg. 32-bit) with the following option to configure. This
+example will produce a 32-bit binary if compiling on a platform which
+defaults to producing 64-bit binaries. The inverse is also possible.
+
+     ../configure --enable-bi=32
+
+     Warning: Currently bi-arch cross-compilation is not supported due
+     to a bug with libtool which fails miserably during linking.
+
+5.4 Solaris
+===========
+
+Building on Solaris is supported. The following are the recommended
+specifications for this platform; but is not necessarily the only
+configuration that is possible:
+
+   * Intel 32-bit or 64-bit hardware
+
+   * Solaris 10u6, gcc 3.4.3
+
+   * gcc 3.4.0 or higher is reported to work
+
+     Note: It is recommended to use the platform distribution's bundled
+     compiler for maximum C++ compatibility. If you build with a custom
+     compiler it will likely introduce non-standard runtime
+     requirements for your users. There are of course many valid
+     reasons to build with unbundled compilers, but be aware that is
+     generally unsupported and left as an exercise to the reader.
+
+     Note: Solaris does not (yet) really bundle a compiler. The
+     recommendation is to use the companion-disk compiler for maximum
+     C++ runtime compatibility. It is usually found in `/usr/sfw/bin'.
+
+5.4.1 Default Binaries
+----------------------
+
+The preferred method to produce default binaries is to run configure
+without any options which will compile with debug+optimize and produce
+static+shared libraries and dynamic executables.
+
+     ../configure
+
+5.4.2 Release Binaries
+----------------------
+
+The preferred method to produce binaries suitable for releases, (ie.
+which does not contain debug information) is to pass the following to
+configure:
+
+     ../configure --disable-debug
+
+5.4.3 Developer Binaries
+------------------------
+
+The preferred method to produce binaries suitable for development is to
+pass the following to configure.  Default Binaries will work, however
+for the best debugging experience we recommend no optimize and no
+static libraries.
+
+     ../configure --disable-optimize --disable-static
+
+5.4.4 Bi-arch compilation
+-------------------------
+
+The preferred method to produce a bi-arch binary is to specify the
+target (eg. 32-bit) with the following option to configure. This
+example will produce a 32-bit binary if compiling on a platform which
+defaults to producing 64-bit binaries. The inverse is also possible.
+
+     ../configure --enable-bi=32
+
+     Warning: Currently bi-arch cross-compilation is not supported due
+     to a bug with libtool which fails miserably during linking.
+
+5.5 Cygwin
+==========
+
+Building on Cygwin is supported. The following are the recommended
+specifications for this platform; but is not necessarily the only
+configuration that is possible:
+
+   * Intel 32-bit or 64-bit hardware
+
+   * Cygwin, gcc 4.3.2
+
+   * gcc 3.4.0 or higher is reported to work
+
+     Note: As of this writing, Cygwin has available to it several
+     versions of gcc; only one of which may be found and used in the
+     path as `gcc' and `g++'. Configure will thus find what is probably
+     the older more stable version of gcc in a typical Cygwin
+     environment. If you desire to build with the newer gcc, it is
+     found in the path as `gcc-4' and `g++-4' respectively and you must
+     indicate to configure the desired versions. Defining the following
+     variables beforing running configure should do the trick:
+
+     setenv CC gcc-4
+     setenv CXX gcc-4
+     ../configure
+
+5.5.1 Default Binaries
+----------------------
+
+The preferred method to produce default binaries is to run configure
+without any options which will compile with debug+optimize and produce
+static+shared libraries and dynamic executables.
+
+     ../configure
+
+5.5.2 Release Binaries
+----------------------
+
+The preferred method to produce binaries suitable for releases, (ie.
+which does not contain debug information) is to pass the following to
+configure:
+
+     ../configure --disable-debug
+
+5.5.3 Developer Binaries
+------------------------
+
+The preferred method to produce binaries suitable for development is to
+pass the following to configure.  Default Binaries will work, however
+for the best debugging experience we recommend no optimize and no
+static libraries.
+
+     ../configure --disable-optimize --disable-static
+
+5.6 Windows
+===========
+
+Native builds on Windows is supported via Microsoft's Visual Studio
+package. Both the commercial version and free version (express) are
+known to work. The following are the recommended specifications for
+this platform; but is not necessarily the only configuration that is
+possible:
+
+   * Intel 32-bit or 64-bit hardware
+
+   * Windows 2000 or higher, Visual Studio 9.0 (aka. Visual Studio 2008)
+
+   * Visual Studio 9.0 Express is reported to work
+
+Only 32-bit binaries are targeted, and win32-API is set to Windows 2000
+or higher. Older versions of Windows, or win32-API are not supported.
+
+MP4v2 has directory `vstudio9.0/' which contains the necessary
+solution+project files to produce a basic build of libmp4v2's DLL and
+several command-line executables. Enabling things such as debugging,
+optimization, etc, are all left as an exercise to the user.
+
+     Warning: Project meta-data is stored in header `project.h'. A
+     proper source distribution is built using autotools and generates
+     `TOP/include/mp4v2/project.h' correctly, which is then bundled
+     with our source distribution. This is adequate for building on the
+     Windows platform.
+
+     However, if you are building from the repository, be warned that
+     there is no method to automatically generate `project.h' on
+     Windows. Instead, we periodically checkin a copy of this file
+     (generated using autotools) as
+     `vstudio9.0/include/mp4v2/project.h' which may from time to time
+     get out of date. If it is significantly out of date, you should
+     find the latest source distribution and copy the `project.h' from
+     there.
+