You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
721 lines
24 KiB
721 lines
24 KiB
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.
|
|
|