Doc: Included/compile.itexi - CG 4.2 - Updated notes on reqs for compiling

[lilypond.git] / Documentation / included / compile.itexi

@c -*- coding: utf-8; mode: texinfo; -*-


@c DO NOT TRANSLATE THIS FILE

@c include any node/sections from the higher-level *texi file.
@c   @n ode Compiling from source
@c   @s ection Compiling from source

@menu
* Overview of compiling::
* Requirements::
* Getting the source code::
* Configuring make::
* Compiling LilyPond::
* Post-compilation options::
* Problems::
* Concurrent stable and development versions::
* Build system::
@end menu


@node Overview of compiling
@section Overview of compiling

Compiling LilyPond from source is an involved process, and is only
recommended for developers and packagers.  Typical program users
are instead encouraged to obtain the program from a package
manager (on Unix) or by downloading a precompiled binary
configured for a specific operating system.  Pre-compiled binaries
are available on the @rweb{Download} page.

Compiling LilyPond from source is necessary if you want to build,
install, or test your own version of the program.

A successful compile can also be used to generate and install the
documentation, incorporating any changes you may have made.
However, a successful compile is not a requirement for generating
the documentation.  The documentation can be built using a Git
repository in conjunction with a locally installed copy of the
program.  For more information, see @ref{Building documentation
without compiling}.

Attempts to compile LilyPond natively on Windows have been
unsuccessful, though a workaround is available (see
@rcontrib{LilyDev}).


@node Requirements
@section Requirements


@menu
* Requirements for running LilyPond::
* Requirements for compiling LilyPond::
* Requirements for building documentation::
@end menu


@node Requirements for running LilyPond
@subsection Requirements for running LilyPond

This section contains the list of separate software packages that are
required to run LilyPond.

@itemize

@item @uref{http://www.dejavu-fonts.org/, DejaVu fonts}
These are normally installed by default.

@item
@uref{http://www.fontconfig.org/, FontConfig}
Use version 2.4.0 or newer.

@item
@uref{http://www.freetype.org/, Freetype}
Use version 2.1.10 or newer.

@item
@uref{http://www.ghostscript.com, Ghostscript}
Use version 8.60 or newer.

@item
@uref{http://www.gnu.org/software/guile/guile.html, Guile}
Use version 1.8.8. Version 2.x of Guile is not currently supported.

@item
@uref{http://www.pango.org/, Pango}
User version 1.12 or newer.

@item
@uref{http://www.python.org, Python}
Use version 2.4 or newer.

@item
International fonts.  For example:

Fedora:

@example
fonts-arabic
fonts-hebrew
fonts-ja
fonts-xorg-truetype
taipeifonts
ttfonts-ja
ttfonts-zh_CN
@end example

Debian based distributions:

@example
emacs-intl-fonts
fonts-ipafont-gothic
fonts-ipafont-mincho
xfonts-bolkhov-75dpi
xfonts-cronyx-75dpi
xfonts-cronyx-100dpi
xfonts-intl-.*
@end example

These are normally installed by default and are required only to create
music with international text or lyrics.

@end itemize


@node Requirements for compiling LilyPond
@subsection Requirements for compiling LilyPond

This section contains instructions on how to quickly and easily get all
the software packages required to build LilyPond.

Most of the more popular Linux distributions only require a few simple
commands to download all the software needed.  For others, there is an
explicit list of all the individual packages (as well as where to get
them from) for those that are not already included in your
distributions' own repositories.

@ignore
I have tested all of the following four Linux Distributions listed here
Using a simple virtual machine and the appropriate ISO image file
downloaded from each distribution's own website.  The instructions
documented were run immediately after the initial installation
(without any further additional configuration to the OS) and I made sure
that I was able to run the full set of make, make test-baseline, make
check and a full make doc. - James
@end ignore

@menu
* Fedora::
* Linux Mint::
* OpenSUSE::
* Ubuntu::
* Other::
@end menu


@node Fedora
@unnumberedsubsubsec Fedora

The following instructions were tested on @q{Fedora 22} and include all
the software to both compile LilyPond and build the documenation.

@itemize

@item
Download and install all the LilyPond build-dependencies (approximately
700MB);

@example
sudo dnf builddep lilypond --nogpgcheck
@end example

@item
Download and install additional @q{build} tools required for compiling;

@example
sudo dnf install autoconf gcc-c++
@end example

@item
Download @code{texi2html 1.82} directly from:
@uref{http://download.savannah.gnu.org/releases/texi2html/texi2html-1.82.tar.gz};

@code{texi2html} is only required if you intend to compile LilyPond's
own documentation (e.g. to help with any document writing).  The version
available in the Fedora repositories is too new and will not work.
Extract the files into an appropriate location and then run the
commands;

@example
./configure
make
sudo make install
@end example

This should install @code{texi2html 1.82} into @code{/usr/local/bin},
which will normally take priority over @code{/usr/bin} where the
later, pre-installed versions gets put.  Now verify that your operating
system is able to see the correct version of @code{texi2html}.

@example
texi2html --version
@end example

@item
Although not @q{required} to compile LilyPond, if you intend to
contribute to LilyPond (codebase or help improve the documentation) then
it is recommended that you also need to install @code{git}.

@example
sudo dnf install git
@end example

Also see @ruser{Starting with Git}.

@item
To use the @code{lily-git.tcl} GUI;

@example
sudo dnf install tk
@end example

See @ruser{lily-git}.

@end itemize



@node Linux Mint
@unnumberedsubsubsec Linux Mint

The following instructions were tested on @q{Linux Mint 17.1} and
@q{LMDE - Betsy} and include all the software to both compile LilyPond
and build the documenation.

@itemize

@item
Enable the @emph{sources} repository;

@enumerate

@item
Using the @emph{Software Sources} GUI (located under
@emph{Administration}).

@item
Select @emph{Official Repositories}.

@item
Check the @emph{Enable source code repositories} box under the
@emph{Source Code} section.

@item
Click the @emph{Update the cache} button and when it has completed,
close the @emph{Software Sources} GUI.

@end enumerate

@item
Download and install all the LilyPond build-dependencies (approximately
200MB);

@example
sudo apt-get build-dep lilypond
@end example

@item
Download and install additional @q{build} tools required for compiling;

@example
sudo apt-get install autoconf fonts-texgyre texlive-lang-cyrillic
@end example

@item
Although not @q{required} to compile LilyPond, if you intend to
contribute to LilyPond (codebase or help improve the documentation) then
it is recommended that you also need to install @code{git}.

@example
sudo apt-get install git
@end example

Also see @ruser{Starting with Git}.

@item
To use the @code{lily-git.tcl} GUI;

@example
sudo apt-get install tk
@end example

Also see @ruser{lily-git}.

@end itemize


@node OpenSUSE
@unnumberedsubsubsec OpenSUSE

The following instructions were tested on @q{OpenSUSE 13.2} and include
all the software to both compile LilyPond and build the documenation.

@itemize

@item
Add the @emph{sources} repository;

@smallexample
sudo zypper addrepo -f \
"http://download.opensuse.org/source/distribution/13.2/repo/oss/" sources
@end smallexample

@item
Download and install all the LilyPond build-dependencies (approximately
680MB);

@example
sudo zypper source-install lilypond
@end example

@item
Download and install additional @q{build} tools required for compiling;

@example
sudo zypper install make
@end example

@item
Although not @q{required} to compile LilyPond, if you intend to
contribute to LilyPond (codebase or help improve the documentation) then
it is recommended that you also need to install @code{git}.

@example
sudo apt-get install git
@end example

Also see @ruser{Starting with Git}.

@item
To use the @code{lily-git.tcl} GUI;

@example
sudo zypper install tk
@end example

Also see @ruser{lily-git}.

@end itemize



@node Ubuntu
@unnumberedsubsubsec Ubuntu

The following commands were tested on Ubuntu versions @code{14.04 LTS},
@code{14.10} and @code{15.04} and include all the software to both
compile LilyPond and build the documenation.

@itemize

@item
Download and install all the LilyPond build-dependencies (approximately
200MB);

@example
sudo apt-get build-dep lilypond
@end example

@item
Download and install additional @q{build} tools required for compiling;

@example
sudo apt-get install autoconf fonts-texgyre texlive-land-cyrillic
@end example

@item
Although not @q{required} to compile LilyPond, if you intend to
contribute to LilyPond (codebase or help improve the documentation) then
it is recommended that you also need to install @code{git}.

@example
sudo apt-get install git
@end example

Also see @ruser{Starting with Git}.

@item
To use the @code{lily-git.tcl} GUI;

@example
sudo apt-get install tk
@end example

Also see @ruser{lily-git}.

@end itemize


@node Other
@unnumberedsubsubsec Other

The following individual software packages are required just to compile
LilyPond.

@itemize

@item
@uref{http://www.gnu.org/software/autoconf, GNU Autoconf}

@item
@uref{http://www.gnu.org/software/bison/, GNU Bison}

Use version @code{2.0} or newer.

@item
@uref{http://gcc.gnu.org/, GNU Compiler Collection}

Use version @code{3.4} or newer (@code{4.x} recommended).

@item
@uref{http://flex.sourceforge.net/, Flex}

@item
@uref{http://fontforge.sf.net/, FontForge}

Use version @code{20060125} or newer (we recommend using at least
@code{20100501}); it must also be compiled with the
@option{--enable-double} switch, else this can lead to inaccurate
intersection calculations which end up with poorly-rendered glyphs in
the output.

@item
@uref{http://www.gnu.org/software/gettext/gettext.html, GNU gettext}

Use version @code{0.17} or newer.

@item
@uref{http://www.gnu.org/software/make/, GNU Make}

Use version @code{3.78} or newer.

@item
@uref{http://metafont.tutorial.free.fr/, MetaFont}

The @code{mf-nowin}, @code{mf}, @code{mfw} or @code{mfont} binaries are
usually packaged along with
@uref{http://www.latex-project.org/ftp.html, @TeX{}}.

@item
@uref{http://cm.bell-labs.com/who/hobby/MetaPost.html, MetaPost}

The @code{mpost} binary is also usually packaged with
@uref{http://www.latex-project.org/ftp.html, @TeX{}}.

@item
@uref{http://www.perl.org/, Perl}

@item
@uref{http://www.gnu.org/software/texinfo/, Texinfo}

Use version @code{4.11} or newer.

@item
@uref{http://www.lcdf.org/~eddietwo/type/#t1utils, Type 1 utilities}

Use version @code{1.33} or newer.

@item
@uref{https://www.ctan.org/pkg/cyrillic?lang=en, Cyrillic fonts}

Often packaged in repositories as @code{texlive-lang-cyrillic}.

@item
TeX Gyre @q{OTF} font packages.  As of LilyPond version @code{2.19.26},
the previous default serif, san serif and monospace fonts now use Tex
Gyre's @emph{Schola}, @emph{Heros} and @emph{Cursor} fonts respectively.
Also See @ruser{Fonts}.

Some distributions do not always provide @q{OTF} font files in the Tex
Gyre packages from their repositories.  Use the command
@code{fc-list | grep texgyre} to list the fonts available to your system
and check that the appropriate @code{*.otf} files are reported.  If they
are not then download and manually extract the @q{OTF} files to either
your local  @code{~/.fonts/} directory or use the
@code{configure} command and the
@code{--with-texgyre-dir=/path_to_otf_files/} option.

The following font families are required:

@uref{http://www.gust.org.pl/projects/e-foundry/tex-gyre/schola, Schola},
@uref{http://www.gust.org.pl/projects/e-foundry/tex-gyre/heros, Heros}
and
@uref{http://www.gust.org.pl/projects/e-foundry/tex-gyre/cursor, Cursor}.

@end itemize



@node Requirements for building documentation
@subsection Requirements for building documentation

The entire set of documentation for the most current build of LilyPond
is available online at
@uref{http://lilypond.org/doc/v2.19/Documentation/web/development}, but
you can also build them locally from the source code.  This process
requires some additional tools and packages.

@warning{If you have used the instructions for one of the Linux
distributions explicitly listed in the previous section
(@rcontrib{Requirements for compiling LilyPond}) then the following can
be ignored as the software should already be installed.}

@itemize

@item
Everything listed in @ref{Requirements for compiling LilyPond}

@item
@uref{http://www.imagemagick.org/, ImageMagick}

@item
@uref{http://netpbm.sourceforge.net/, Netpbm}

@item
@uref{http://gzip.org/, gzip}

@item
@uref{http://rsync.samba.org/, rsync}

@item
@uref{http://www.nongnu.org/texi2html/, Texi2HTML}

Use version @code{1.82}.  Later versions will not work.

Download @code{texi2html 1.82} directly from:
@uref{http://download.savannah.gnu.org/releases/texi2html/texi2html-1.82.tar.gz};

Extract the files into an appropriate location and then run the
commands;

@example
./configure
make
sudo make install
@end example

Now verify that your operating system is able to see the correct version
of @code{texi2html}.

@example
texi2html --version
@end example

@item
Fonts required to build the documentation in addition to those required
to run LilyPond:

@example
gsfonts
fonts-linuxlibertine
fonts-liberation
fonts-dejavu
fonts-freefont-otf
ttf-bitstream-vera
texlive-fonts-recommended
ttf-xfree86-nonfree
@end example

@end itemize



@node Getting the source code
@section Getting the source code


@subheading Downloading the Git repository

In general, developers compile LilyPond from within a local Git
repository.  Setting up a local Git repository is explained in
@rcontrib{Starting with Git}.


@subheading Downloading a source tarball

Packagers are encouraged to use source tarballs for compiling.

The tarball for the latest stable release is available on the
@rweb{Source} page.

@noindent
The latest
@uref{http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=snapshot, source code snapshot}
is also available as a tarball from the GNU Savannah Git server.

@noindent
All tagged releases (including legacy stable
versions and the most recent development release) are available
here:

@example
@uref{http://download.linuxaudio.org/lilypond/source/}
@end example

Download the tarball to your @file{~/src/} directory, or some
other appropriate place.

@warning{Be careful where you unpack the tarball!  Any
subdirectories of the current folder named @file{lilypond/} or
@file{lilypond-@var{x.y.z}/} (where @var{x.y.z} is the release
number) will be overwritten if there is a name clash with the
tarball.}

Unpack the tarball with this command:

@example
tar -xzf lilypond-@var{x.y.z}.tar.gz
@end example

This creates a subdirectory within the current directory called
@file{lilypond-@var{x.y.z}/}.  Once unpacked, the source files
occupy about 40 MB of disk space.

Windows users wanting to look at the source code may have to
download and install the free-software
@uref{http://www.7-zip.org, 7zip archiver} to extract the tarball.


@node Configuring make
@section Configuring @command{make}


@menu
* Running ./autogen.sh::
* Running ../configure::
@end menu


@node Running ./autogen.sh
@subsection Running @command{./autogen.sh}

After you unpack the tarball (or download the Git repository), the
contents of your top source directory should be similar to the
current source tree listed at
@uref{http://git.sv.gnu.org/gitweb/?p=lilypond.git;a=tree}.

Next, you need to create the generated files; enter the following
command from your top source directory:

@example
./autogen.sh --noconfigure
@end example

This will generate a number of files and directories to aid
configuration, such as @file{configure}, @file{README.txt}, etc.

Next, create the build directory with:

@example
mkdir build/
cd build/
@end example

We heavily recommend building lilypond inside a separate directory
with this method.


@node Running ../configure
@subsection Running @command{../configure}


@menu
* Configuration options::
* Checking build dependencies::
* Configuring target directories::
@end menu


@node Configuration options
@unnumberedsubsubsec Configuration options

@warning{make sure that you are in the @file{build/} subdirectory
of your source tree.}

The @command{../configure} command (generated by
@command{./autogen.sh}) provides many options for configuring
@command{make}.  To see them all, run:

@example
../configure --help
@end example


@node Checking build dependencies
@unnumberedsubsubsec Checking build dependencies

@warning{make sure that you are in the @file{build/} subdirectory
of your source tree.}

When @command{../configure} is run without any arguments, it will
check to make sure your system has everything required for
compilation:

@example
../configure
@end example

If any build dependency is missing, @command{../configure} will
return with:

@example
ERROR: Please install required programs:  @var{foo}
@end example

The following message is issued if you are missing programs that
are only needed for building the documentation:

@example
WARNING: Please consider installing optional programs:  @var{bar}
@end example

If you intend to build the documentation locally, you will need to
install or update these programs accordingly.

@warning{@command{../configure} may fail to issue warnings for
certain documentation build requirements that are not met.  If you
experience problems when building the documentation, you may need
to do a manual check of @ref{Requirements for building
documentation}.}


@node Configuring target directories
@unnumberedsubsubsec Configuring target directories

@warning{make sure that you are in the @file{build/} subdirectory
of your source tree.}

If you intend to use your local build to install a local copy of
the program, you will probably want to configure the installation
directory.  Here are the relevant lines taken from the output of
@command{../configure@tie{}--help}:

@quotation
By default, `@command{make@tie{}install}' will install all the
files in @file{/usr/local/bin}, @file{/usr/local/lib} etc.  You
can specify an installation prefix other than @file{/usr/local}
using `@option{--prefix}', for instance `@option{--prefix=$HOME}'.
@end quotation

A typical installation prefix is @file{$HOME/usr}:

@example
../configure --prefix=$HOME/usr
@end example

Note that if you plan to install a local build on a system where
you do not have root privileges, you will need to do something
like this anyway---@command{make@tie{}install} will only succeed
if the installation prefix points to a directory where you have
write permission (such as your home directory).  The installation
directory will be automatically created if necessary.

The location of the @command{lilypond} command installed by this
process will be @file{@var{prefix}/bin/lilypond}; you may want to
add @file{@var{prefix}/bin/} to your @code{$PATH} if it is not
already included.

It is also possible to specify separate installation directories
for different types of program files.  See the full output of
@command{../configure@tie{}--help} for more information.

If you encounter any problems, please see @ref{Problems}.


@node Compiling LilyPond
@section Compiling LilyPond


@menu
* Using make::
* Saving time with the -j option::
* Compiling for multiple platforms::
* Useful make variables::
@end menu


@node Using make
@subsection Using @command{make}

@warning{make sure that you are in the @file{build/} subdirectory
of your source tree.}

LilyPond is compiled with the @command{make} command.  Assuming
@command{make} is configured properly, you can simply run:

@example
make
@end example

@samp{make} is short for @samp{make all}.  To view a list of @command{make}
targets, run:

@example
make help
@end example

TODO: Describe what @command{make} actually does.

@seealso
@ref{Generating documentation} provides more info on the @command{make} targets
used to build the LilyPond documentation.


@node Saving time with the -j option
@subsection Saving time with the @option{-j} option

If your system has multiple CPUs, you can speed up compilation by
adding @samp{-j@var{X}} to the @command{make} command, where
@samp{@var{X}} is one more than the number of cores you have.  For
example, a typical Core2Duo machine would use:

@example
make -j3
@end example

If you get errors using the @option{-j} option, and @samp{make}
succeeds without it, try lowering the @code{@var{X}} value.

Because multiple jobs run in parallel when @option{-j} is used, it can
be difficult to determine the source of an error when one occurs.  In
that case, running @samp{make} without the @option{-j} is advised.

@node Compiling for multiple platforms
@subsection Compiling for multiple platforms

If you want to build multiple versions of LilyPond with different
configuration settings, you can use the
@option{--enable-config=@var{conf}} option of @command{configure}.
You should use @code{make@tie{}conf=@var{conf}} to generate the
output in @file{out-@var{conf}}.  For example, suppose you want to
build with and without profiling, then use the following for the
normal build

@example
./configure --prefix=$HOME/usr/ --enable-checking
make
@end example

and for the profiling version, specify a different configuration

@example
./configure --prefix=$HOME/usr/ --enable-profiling \
  --enable-config=prof --disable-checking
make conf=prof
@end example

If you wish to install a copy of the build with profiling, don't
forget to use @code{conf=@var{CONF}} when issuing
@command{make@tie{}install}:

@example
make conf=prof install
@end example


@seealso
@ref{Installing LilyPond from a local build}


@node Useful make variables
@subsection Useful @command{make} variables

If a less verbose build output if desired, the variable
@code{QUIET_BUILD} may be set to @code{1} on @command{make}
command line, or in @file{local.make} at top of the build tree.


@node Post-compilation options
@section Post-compilation options


@menu
* Installing LilyPond from a local build::
* Generating documentation::
* Testing LilyPond binary::
@end menu


@node Installing LilyPond from a local build
@subsection Installing LilyPond from a local build

If you configured @command{make} to install your local build in a
directory where you normally have write permission (such as your
home directory), and you have compiled LilyPond by running
@command{make}, you can install the program in your target
directory by running:

@example
make install
@end example

If instead, your installation directory is not one that you can
normally write to (such as the default @file{/usr/local/}, which
typically is only writeable by the superuser), you will need to
temporarily become the superuser when running
@command{make@tie{}install}:

@example
sudo make install
@end example

@noindent
or@dots{}

@example
su -c 'make install'
@end example

If you don't have superuser privileges, then you need to configure
the installation directory to one that you can write to, and then
re-install.  See @ref{Configuring target directories}.


@node Generating documentation
@subsection Generating documentation


@menu
* Documentation editor's edit/compile cycle::
* Building documentation::
* Building a single document::
* Saving time with CPU_COUNT::
* AJAX search::
* Installing documentation::
* Building documentation without compiling::
@end menu


@node Documentation editor's edit/compile cycle
@unnumberedsubsubsec Documentation editor's edit/compile cycle

@itemize
@item
Initial documentation build:

@example
make [-j@var{X}]
make [-j@var{X} CPU_COUNT=@var{X}] doc          @emph{## can take an hour or more}
make [-j@var{X} CPU_COUNT=@var{X}] doc-stage-1  @emph{## to build only PDF documentation}
@end example

@item
Edit/compile cycle:

@example
@emph{## edit source files, then@dots{}}

make [-j@var{X}]                  @emph{## needed if editing outside}
                            @emph{##   Documentation/, but useful anyway}
                            @emph{##   for finding Texinfo errors.}
make [-j@var{X} CPU_COUNT=@var{X}] doc  @emph{## usually faster than initial build.}
@end example

@item
Reset:

It is generally possible to remove the compiled documentation from
your system
with @samp{make@tie{}doc-clean}, but this method is not 100%
guaranteed.  Instead, if you want to be sure you have a clean
system, we recommend that you delete your
@file{build/} directory, and begin compiling from scratch.  Since
the documentation compile takes much longer than the
non-documentation compile, this does not increase the overall time
by a great deal.

@end itemize

@node Building documentation
@unnumberedsubsubsec Building documentation

After a successful compile (using @command{make}), the
documentation can be built by issuing:

@example
make doc
@end example

or, to build only the PDF documentation and not the HTML,

@example
make doc-stage-1
@end example

@warning{The first time you run @command{make@tie{}doc}, the
process can easily take an hour or more with not much output
on the command line.}

After this initial build, @command{make@tie{}doc} only makes
changes to the documentation where needed, so it may only take
a minute or two to test changes if the documentation is already
built.

If @command{make@tie{}doc} succeeds, the HTML documentation tree
is available in @file{out-www/offline-root/}, and can be browsed
locally.  Various portions of the documentation can be found by
looking in @file{out/} and @file{out-www} subdirectories in other
places in the source tree, but these are only @emph{portions} of
the docs.  Please do not complain about anything which is broken
in those places; the only complete set of documentation is in
@file{out-www/offline-root/} from the top of the source tree.

@command{make@tie{}doc} sends the output from most of the
compilation to logfiles.  If the build fails for any reason, it
should prompt you with the name of a logfile which will provide
information to help you work out why the build failed.  These
logfiles are not deleted with @command{make@tie{}doc-clean}.  To
remove all the logfiles generated by the compilation process, use:

@example
make log-clean
@end example

@code{make@tie{}doc} compiles the documents for all languages.  To
save some compile time, the English language documents can be
compiled on their own with:

@example
make LANGS='' doc
@end example

@noindent Similarly, it is possible to compile a subset of the
translated documentation by specifying their language codes on the
command line.  For example, the French and German translations are
compiled with:

@example
make LANGS='de fr' doc
@end example

@noindent Note that this will also compile the English version.

Compilation of documentation in Info format with images can be
done separately by issuing:

@example
make info
@end example

@noindent
An issue when switching branches between master and translation
is the appearance/disappearance of translated versions of some manuals.
If you see such a warning from make:

@example
No rule to make target `X', needed by `Y'
@end example

@noindent
Your best bet is to delete the file Y.dep and to try again.

@node Building a single document
@unnumberedsubsubsec Building a single document
It's possible to build a single document.  For example, to rebuild
only @file{contributor.pdf}, do the following:

@example
cd build/
cd Documentation/
touch ../../Documentation/contributor.texi
make out=www out-www/contributor.pdf
@end example

If you are only working on a single document, test-building it in
this way can give substantial time savings - recreating
@file{contributor.pdf}, for example, takes a matter of seconds.

@node Saving time with CPU_COUNT
@unnumberedsubsubsec Saving time with @code{CPU_COUNT}

The most time consuming task for building the documentation is
running LilyPond to build images of music, and there cannot be
several simultaneously running @command{lilypond-book} instances,
so the @option{-j} @command{make} option does not significantly
speed up the build process.  To help speed it up, the makefile
variable @option{CPU_COUNT} may be set in @file{local.make} or on
the command line to the number of @code{.ly} files that LilyPond
should process simultaneously, e.g. on a bi-processor or dual core
machine:

@example
make -j3 CPU_COUNT=3 doc
@end example

@noindent
The recommended value of @option{CPU_COUNT} is one plus the number
of cores or processors, but it is advisable to set it to a smaller
value unless your system has enough RAM to run that many
simultaneous LilyPond instances.  Also, values for the @option{-j}
option that pose problems with @samp{make} are less likely to pose
problems with @samp{make doc} (this applies to both @option{-j}
and @option{CPU_COUNT}).  For example, with a quad-core processor,
it is possible for @samp{make -j5 CPU_COUNT=5 doc} to work
consistently even if @samp{make -j5} rarely succeeds.


@node AJAX search
@unnumberedsubsubsec AJAX search

To build the documentation with interactive searching, use:

@example
make doc AJAX_SEARCH=1
@end example

This requires PHP, and you must view the docs via a http
connection (you cannot view them on your local filesystem).

@warning{Due to potential security or load issues, this option is
not enabled in the official documentation builds.  Enable at your
own risk.}


@node Installing documentation
@unnumberedsubsubsec Installing documentation

The HTML, PDF and if available Info files can be installed into
the standard documentation path by issuing

@example
make install-doc
@end example

@noindent
This also installs Info documentation with images if the
installation prefix is properly set; otherwise, instructions to
complete proper installation of Info documentation are printed on
standard output.

To install the Info documentation separately, run:

@example
make install-info
@end example

@noindent
Note that to get the images in Info documentation, @code{install-doc}
target creates symbolic links to HTML and PDF installed documentation
tree in @file{@var{prefix}/share/info}, in order to save disk space,
whereas @code{install-info} copies images in
@file{@var{prefix}/share/info} subdirectories.

It is possible to build a documentation tree in
@file{out-www/online-root/}, with special processing, so it can be
used on a website with content negotiation for automatic language
selection; this can be achieved by issuing

@example
make WEB_TARGETS=online doc
@end example

@noindent
and both @q{offline} and @q{online} targets can be generated by issuing

@example
make WEB_TARGETS="offline online" doc
@end example

Several targets are available to clean the documentation build and
help with maintaining documentation; an overview of these targets is
available with

@example
make help
@end example

@noindent
from every directory in the build tree.  Most targets for
documentation maintenance are available from
@file{Documentation/}; for more information, see
@rcontrib{Documentation work}.

The makefile variable @code{QUIET_BUILD} may be set to @code{1}
for a less verbose build output, just like for building the
programs.


@node Building documentation without compiling
@unnumberedsubsubsec Building documentation without compiling


The documentation can be built locally without compiling LilyPond
binary, if LilyPond is already installed on your system.

From a fresh Git checkout, do

@example
./autogen.sh   # ignore any warning messages
cp GNUmakefile.in GNUmakefile
make -C scripts && make -C python
nice make LILYPOND_EXTERNAL_BINARY=/path/to/bin/lilypond doc
@end example

Please note that this may break sometimes -- for example, if a new
feature is added with a test file in input/regression, even the latest
development release of LilyPond will fail to build the docs.

You may build the manual without building all the @file{input/*} stuff
(i.e. mostly regression tests): change directory, for example to
@file{Documentation/}, issue @code{make doc}, which will build
documentation in a subdirectory @file{out-www} from the source files in
current directory.  In this case, if you also want to browse the
documentation in its post-processed form, change back to top directory
and issue

@example
make out=www WWW-post
@end example

@knownissues

You may also need to create a script for @command{pngtopnm} and
@code{pnmtopng}.  On GNU/Linux, I use this:

@verbatim
export LD_LIBRARY_PATH=/usr/lib
exec /usr/bin/pngtopnm "$@"
@end verbatim

On MacOS X with fink, I use this:

@verbatim
export DYLD_LIBRARY_PATH=/sw/lib
exec /sw/bin/pngtopnm "$@"
@end verbatim

On MacOS X with macports, you should use this:

@verbatim
export DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib
exec /opt/local/bin/pngtopnm "$@"
@end verbatim


@node Testing LilyPond binary
@subsection Testing LilyPond binary


LilyPond comes with an extensive suite that exercises the entire
program.  This suite can be used to test that the binary has
been built correctly.

The test suite can be executed with:

@verbatim
make test
@end verbatim

If the test suite completes successfully, the LilyPond binary
has been verified.

More information on the regression test suite is found at
@rcontrib{Regression tests}.

@node Problems
@section Problems

For help and questions use @email{lilypond-user@@gnu.org}.  Send
bug reports to @email{bug-lilypond@@gnu.org}.

Bugs that are not fault of LilyPond are documented here.


@unnumberedsubsec Compiling on MacOS@tie{}X

Here are special instructions for compiling under MacOS@tie{}X.
These instructions assume that dependencies are installed using
@uref{http://www.macports.org/, MacPorts.} The instructions have
been tested using OS X 10.5 (Leopard).

First, install the relevant dependencies using MacPorts.

Next, add the following to your relevant shell initialization
files.  This is @code{~/.profile} by default.  You should create
this file if it does not exist.

@example
export PATH=/opt/local/bin:/opt/local/sbin:$PATH
export DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib:$DYLD_FALLBACK_LIBRARY_PATH
@end example

Now you must edit the generated @file{config.make} file.  Change

@example
FLEXLEXER_FILE = /usr/include/FlexLexer.h
@end example

@noindent
to:

@example
FLEXLEXER_FILE = /opt/local/include/FlexLexer.h
@end example

At this point, you should verify that you have the appropriate
fonts installed with your ghostscript installation.  Check @code{ls
/opt/local/share/ghostscript/fonts} for: 'c0590*' files (.pfb,
.pfb and .afm).  If you don't have them, run the following
commands to grab them from the ghostscript SVN server and install
them in the appropriate location:

@example
svn export http://svn.ghostscript.com/ghostscript/tags/urw-fonts-1.0.7pre44/
sudo mv urw-fonts-1.0.7pre44/* /opt/local/share/ghostscript/fonts/
rm -rf urw-fonts-1.07pre44
@end example

Now run the @code{./configure} script.  To avoid complications with
automatic font detection, add

@example
--with-fonts-dir=/opt/local/share/ghostscript/fonts
@end example


@unnumberedsubsec Solaris

Solaris7, ./configure

@file{./configure} needs a POSIX compliant shell.  On Solaris7,
@file{/bin/sh} is not yet POSIX compliant, but @file{/bin/ksh} or bash
is.  Run configure like

@example
CONFIG_SHELL=/bin/ksh ksh -c ./configure
@end example

@noindent
or

@example
CONFIG_SHELL=/bin/bash bash -c ./configure
@end example

@unnumberedsubsec FreeBSD

To use system fonts, dejaview must be installed.  With the default
port, the fonts are installed in @file{usr/X11R6/lib/X11/fonts/dejavu}.

Open the file @file{$LILYPONDBASE/usr/etc/fonts/local.conf} and add the
following line just after the @code{<fontconfig>} line.  (Adjust as necessary
for your hierarchy.)

@example
<dir>/usr/X11R6/lib/X11/fonts</dir>
@end example


@unnumberedsubsec International fonts

On Mac OS X, all fonts are installed by default.  However, finding all
system fonts requires a bit of configuration; see
@uref{http://lists.gnu.org/archive/html/lilypond-user/2007-03/msg00472.html,
this post} on the @code{lilypond-user} mailing list.

On Linux, international fonts are installed by different means on
every distribution.  We cannot list the exact commands or packages
that are necessary, as each distribution is different, and the exact
package names within each distribution changes.  Here are some
hints, though:

@verbatim
Red Hat Fedora

    taipeifonts fonts-xorg-truetype ttfonts-ja fonts-arabic \
         ttfonts-zh_CN fonts-ja fonts-hebrew

Debian GNU/Linux

   apt-get install emacs-intl-fonts xfonts-intl-.* \
        fonts-ipafont-gothic  fonts-ipafont-mincho \
        xfonts-bolkhov-75dpi xfonts-cronyx-100dpi xfonts-cronyx-75dpi
@end verbatim


@unnumberedsubsec Using lilypond python libraries

If you want to use lilypond's python libraries (either running
certain build scripts manually, or using them in other programs),
set @code{PYTHONPATH} to @file{python/out} in your build
directory, or @file{@dots{}/usr/lib/lilypond/current/python} in the
installation directory structure.




@node Concurrent stable and development versions
@section Concurrent stable and development versions


It can be useful to have both the stable and the development versions
of Lilypond available at once.  One way to do this on GNU/Linux is to
install the stable version using the precompiled binary, and run the
development version from the source tree.  After running @command{make
all} from the top directory of the Lilypond source files, there will
be a binary called @code{lilypond} in the @code{out} directory:

@example
<@var{path to}>/lilypond/out/bin/lilypond
@end example

This binary can be run without actually doing the @code{make
install} command.  The advantage to this is that you can have all
of the latest changes available after pulling from git and running
@code{make all}, without having to uninstall the old version and
reinstall the new.

So, to use the stable version, install it as usual and use the
normal commands:

@example
lilypond foobar.ly
@end example

To use the development version, create a link to the binary in the
source tree by saving the following line in a file somewhere in your
@code{$PATH}:

@example
exec <@var{path to}>/lilypond/out/bin/lilypond "$@@"
@end example

Save it as @code{Lilypond} (with a capital L to distinguish it
from the stable @code{lilypond}), and make it executable:

@example
chmod +x Lilypond
@end example

Then you can invoke the development version this way:

@example
Lilypond foobar.ly
@end example


TODO: ADD

- other compilation tricks for developers


@node Build system
@section Build system


We currently use make and stepmake, which is complicated and only
used by us.  Hopefully this will change in the future.


@subheading Version-specific texinfo macros

@itemize

@item
made with @command{scripts/build/create-version-itexi.py} and@*
@command{scripts/build/create-weblinks-itexi.py}

@item
used extensively in the @code{WEBSITE_ONLY_BUILD} version of the
website (made with @file{website.make}, used on lilypond.org)

@item
not (?) used in the main docs?

@item
the numbers in VERSION file: MINOR_VERSION should be 1 more than
the last release, VERSION_DEVEL should be the last @strong{online}
release.  Yes, VERSION_DEVEL is less than VERSION.

@end itemize