diff options
Diffstat (limited to 'debian/mp4v2/mp4v2-2.0.0~dfsg0/doc/BuildRepository.txt')
| -rw-r--r-- | debian/mp4v2/mp4v2-2.0.0~dfsg0/doc/BuildRepository.txt | 720 |
1 files changed, 0 insertions, 720 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 deleted file mode 100644 index aab40aa8..00000000 --- a/debian/mp4v2/mp4v2-2.0.0~dfsg0/doc/BuildRepository.txt +++ /dev/null @@ -1,720 +0,0 @@ -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. - |