@c @s ection Compiling from source
@menu
-* Downloading source code::
+* Overview of compiling::
* Requirements::
-* Building LilyPond::
-* Building documentation::
-* Testing LilyPond::
+* Getting the source code::
+* Configuring make::
+* Compiling LilyPond::
+* Post-compilation options::
* Problems::
+* Concurrent stable and development versions::
+* Build system::
@end menu
-@node Downloading source code
-@subsection Downloading source code
-Download source
+@node Overview of compiling
+@section Overview of compiling
-@itemize
-@item tarballs from
-@uref{http://lilypond.org/download/} by HTTP.
-@item tarballs from
-@uref{http://download.linuxaudio.org/lilypond/} by HTTP.
-@item
-GIT from @uref{http://git.sv.gnu.org/gitweb/?p=lilypond.git;a=summary,git.sv.gnu.org}
+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.
-@example
-git clone git://git.sv.gnu.org/lilypond.git
-@end example
+Compiling LilyPond from source is necessary if you want to build,
+install, or test your own version of the program.
-The repository does not contain generated files. To create
-@file{configure}, run
-@example
-./autogen.sh
-@end example
-@end itemize
+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}.
-For information on packaging, see @uref{http://lilypond.org/devel}.
+Attempts to compile LilyPond natively on Windows have been
+unsuccessful, though a workaround is available (see
+@rcontrib{LilyDev}).
@node Requirements
-@subsection Requirements
+@section Requirements
+
+
+@menu
+* Requirements for running LilyPond::
+* Requirements for compiling LilyPond::
+* Requirements for building documentation::
+@end menu
-@unnumberedsubsubsec Compilation
-In addition to the packages needed for running LilyPond (see below), you
-need the following extra packages for building.
+@node Requirements for running LilyPond
+@subsection Requirements for running LilyPond
-Below is a full list of packages needed to build LilyPond. However, for
-most common distributions there is an easy way of installing most all
-build dependencies in one go
+Running LilyPond requires proper installation of the following
+software:
-@multitable @columnfractions .5 .5
-@headitem Distribution
-@tab Command
+@itemize
+@item @uref{http://www.dejavu-fonts.org/, DejaVu fonts} (normally
+installed by default)
+
+@item @uref{http://www.fontconfig.org/, FontConfig} (2.4.0 or newer)
+
+@item @uref{http://www.freetype.org/, Freetype} (2.1.10 or newer)
+
+@item @uref{http://www.ghostscript.com, Ghostscript} (8.60 or
+newer)
+
+@item @uref{http://www.gnu.org/software/guile/guile.html, Guile}
+(1.8.8 - version 2.x is not currently supported)
+
+@item @uref{http://www.pango.org/, Pango} (1.12 or newer)
+
+@item @uref{http://www.python.org, Python} (2.4 or newer)
+@end itemize
+
+International fonts are required to create music with
+international text or lyrics.
+
+
+@node Requirements for compiling LilyPond
+@subsection Requirements for compiling LilyPond
+
+Below is a full list of packages needed to build LilyPond.
+However, for most common distributions there is an easy way of
+installing most all build dependencies in one go:
+@multitable @columnfractions .5 .5
+@headitem Distribution @tab Command
@item Debian, Ubuntu
@tab @code{sudo apt-get build-dep lilypond}
@c sorry for the idiosyncratic command, I really asked and argued
@c for "zypper build-dep" :-(
@tab @code{sudo zypper --build-deps-only source-install lilypond}
-
@end multitable
-When installing a binary package FOO, you may need to install the
-FOO-devel, libFOO-dev or FOO-dev package too.
-
@itemize
+@item Everything listed in @ref{Requirements for running
+LilyPond}
-@item @uref{http://fontforge.sf.net/,FontForge} 20060125 or newer.
+@item Development packages for the above items (which should
+include header files and libraries).
-@item @uref{http://metafont.tutorial.free.fr/,MetaFont} (mf-nowin, mf, mfw or
-mfont binaries) and @uref{http://cm.bell-labs.com/who/hobby/MetaPost.html,MetaPost}
-(mpost binary), usually packaged with a @LaTeX{} distribution like
-tetex or texlive.
+Red Hat Fedora:
+
+@c ghostscript-devel-[version] isn't needed
+@example
+guile-devel-@var{version}
+fontconfig-devel-@var{version}
+freetype-devel-@var{version}
+pango-devel-@var{version}
+python-devel-@var{version}
+@end example
-@item @uref{http://www.lcdf.org/~eddietwo/type/#t1utils,t1utils}
-(version 1.33 or newer recommended).
+Debian GNU/Linux:
-@item New Century Schoolbook fonts, as PFB files. These are shipped with
-X11 and Ghostscript, and are named @file{c059033l.pfb}
-@file{c059036l.pfb}, @file{c059013l.pfb} and @file{c059016l.pfb}.
+@c libgs-dev isn't needed
+@example
+guile-@var{version}-dev
+libfontconfig1-dev
+libfreetype6-dev
+libpango1.0-dev
+python@var{version}-dev
+@end example
-@item @uref{http://www.gnu.org/software/guile/guile.html,GUILE} (version
-1.8.2 or newer). If you are installing binary packages, you may need to
-install guile-devel or guile-dev or libguile-dev too.
+@item @uref{http://flex.sourceforge.net/, Flex}
-@item @uref{ftp://ftp.gnu.org/gnu/texinfo/,Texinfo} (version 4.11 or newer).
+@item @uref{http://fontforge.sf.net/, FontForge} (20060125 or
+newer; 20100501 or newer is recommended; must be compiled
+with @option{--enable-double}. Failure to do so can lead to
+poor intersection calculations and poorly-rendered glyphs.)
-@item @uref{http://gcc.gnu.org/, The GNU c++ compiler} (version 3.4 or
-newer. 4.x is strongly recommended).
+@item @uref{http://www.gnu.org/software/bison/, GNU Bison}
-@item @uref{http://www.python.org,Python} (version 2.4 or newer)
+@item @uref{http://gcc.gnu.org/, GNU Compiler Collection} (3.4 or
+newer, 4.@var{x} recommended)
-@item @uref{ftp://ftp.gnu.org/gnu/make/,GNU Make} (version 3.78 or newer).
+@item @uref{http://www.gnu.org/software/gettext/gettext.html, GNU
+gettext} (0.17 or newer)
-@item @uref{http://www.gnu.org/software/gettext/gettext.html,gettext}
-(version 0.17 or newer).
+@item @uref{http://www.gnu.org/software/make/, GNU Make} (3.78 or
+newer)
-@item @uref{http://www.gnu.org/software/flex/,Flex}.
+@item @uref{http://metafont.tutorial.free.fr/, MetaFont}
+(mf-nowin, mf, mfw or mfont binaries), usually packaged with
+@uref{http://www.latex-project.org/ftp.html, @TeX{}}.
-@item @uref{http://www.perl.org/,Perl}.
+@item @uref{http://cm.bell-labs.com/who/hobby/MetaPost.html,
+MetaPost} (mpost binary), usually packaged with
+@uref{http://www.latex-project.org/ftp.html, @TeX{}}.
-@item @uref{http://www.gnu.org/software/bison/,GNU Bison}.
+@item @uref{http://www.perl.org/, Perl}
-@item All packages required for running, including development packages with
-header files and libraries.
+@item @uref{http://www.gnu.org/software/texinfo/, Texinfo} (4.11
+or newer)
+@item @uref{http://www.lcdf.org/~eddietwo/type/#t1utils, Type 1
+utilities} (1.33 or newer recommended)
@end itemize
-@unnumberedsubsubsec Running requirements
+@node Requirements for building documentation
+@subsection Requirements for building documentation
-Running LilyPond requires proper installation of the following software
+You can view the documentation online at
+@uref{http://www.lilypond.org/doc/}, but you can also build it
+locally. This process requires some additional tools and
+packages:
@itemize
+@item Everything listed in @ref{Requirements for compiling
+LilyPond}
-@item @uref{http://www.freetype.org/,Freetype} (version 2.1.10 or newer).
-@item @uref{http://fontconfig.org/,FontConfig} (version 2.2 or newer).
-@item @uref{http://www.pango.org/,Pango} (version 1.12 or newer).
-@item @uref{http://www.gnu.org/software/guile/guile.html,GUILE}
-(version 1.8.2 or newer)
-@item @uref{http://www.python.org,Python} (version 2.4 or newer).
-@item @uref{http://www.ghostscript.com,Ghostscript} (version 8.60 or
-newer).
-@item Dejaview. (This is normally installed by default)
-@end itemize
+@item @uref{http://www.imagemagick.org/, ImageMagick}
-International fonts are required to create music with international text
-or lyrics.
+@item @uref{http://netpbm.sourceforge.net/, Netpbm}
+@item @uref{http://gzip.org/, gzip}
-@unnumberedsubsubsec Requirements for building documentation
+@item @uref{http://rsync.samba.org/, rsync}
-You can view the documentation online at
-@uref{http://lilypond.org/doc/}, but you can also build it locally.
-This process requires a successful compile of LilyPond, and some
-additional tools and packages:
+@item @uref{http://www.nongnu.org/texi2html/, Texi2HTML} (1.82)
-@itemize
-@item The @uref{http://netpbm.sourceforge.net/,netpbm utilities}
-@item ImageMagick
-@item International fonts (see input/regression/utf-8.ly for hints
-about which font packages are necessary for your platform)
-@item Ghostscript 8.60 or newer
-@item @uref{http://www.nongnu.org/texi2html/,Texi2HTML} 1.82
-@item rsync
+@item International fonts
+
+Red Hat Fedora:
+
+@example
+fonts-arabic
+fonts-hebrew
+fonts-ja
+fonts-xorg-truetype
+taipeifonts
+ttfonts-ja
+ttfonts-zh_CN
+@end example
+
+Debian GNU/Linux:
+
+@example
+emacs-intl-fonts
+ttf-kochi-gothic
+ttf-kochi-mincho
+xfonts-bolkhov-75dpi
+xfonts-cronyx-75dpi
+xfonts-cronyx-100dpi
+xfonts-intl-.*
+@end example
@end itemize
-@node Building LilyPond
-@subsection Building LilyPond
+@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
-@unnumberedsubsubsec Compiling
+Packagers are encouraged to use source tarballs for compiling.
-To install GNU LilyPond, type
+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
-gunzip -c lilypond-x.y.z | tar xf -
-cd lilypond-x.y.z
-./configure # run with --help for applicable options
-make
-su -c 'make install'
+@uref{http://download.linuxaudio.org/lilypond/source/}
@end example
-@noindent
-If you are not root, you should choose a @code{--prefix} argument that
-points into your home directory, e.g.
+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 --prefix=$HOME/usr
+../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}.
-@unnumberedsubsubsec Compiling for multiple platforms
+@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 @code{--enable-config=CONF}
-option of @command{configure}. You should use @code{make conf=CONF}
-to generate the output in @file{out-CONF}. For example, suppose you
-want to build with and without profiling, then use the following for
-the normal build
+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
-make install
@end example
and for the profiling version, specify a different configuration
@example
-./configure --prefix=$HOME/usr/ --enable-profiling --enable-config=prof --disable-checking
+./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
-@unnumberedsubsubsec Compiling outside the source tree
+@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
-It is possible to compile LilyPond in a build tree different from the
-source tree, with @code{--srcdir} option of @command{configure}:
+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
-mkdir lily-build && cd lily-build
-@var{sourcedir}/configure --srcdir=@var{sourcedir}
+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{}
-@unnumberedsubsubsec Useful @command{make} variables
+@example
+su -c 'make install'
+@end example
-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.
+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 Building documentation
-@subsection Building documentation
+@node Generating documentation
+@subsection Generating documentation
-This requires a successful compile of LilyPond, or using an external
-LilyPond binary.
@menu
-* Commands for building documentation:: Compiling and installing the documentation.
-* Building documentation without compiling LilyPond:: Using a LilyPond binary already installed.
+* 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 Commands for building documentation
-@unnumberedsubsubsec Commands for building documentation
-The documentation is built by issuing
+@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
-After compilation, 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
+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.
-The HTML, PDF and if available Info files can be installed into the
-standard documentation path by issuing
+@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 install-doc
+make log-clean
@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.
+@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
-Compilation of documentation in Info format with images can be done
-separately by issuing
+@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
-Separate installation of this documentation is done by issuing
+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
@noindent
from every directory in the build tree. Most targets for
-documentation maintenance are available from @file{Documentation/};
-@c FIXME: xref to CG
-for more information, see the Contributor's Guide, section
-@emph{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.
-
-
-@knownissues
-
-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 @code{-j}
-@command{make} option does not significantly speed up the build process.
-To help speed it up, the makefile variable @var{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 @var{CPU_COUNT} is one plus the number of
-cores or processors, but it is advisable to set it to a smaller value
-if your system has not enough RAM to run that many simultaneous
-LilyPond instances.
+documentation maintenance are available from
+@file{Documentation/}; for more information, see
+@rcontrib{Documentation work}.
-If source files have changed since last documentation build, output
-files that need to be rebuilt are normally rebuilt, even if you do not
-run @code{make doc-clean} first. However, building dependencies in the
-documentation are so complex that rebuilding of some targets may not
-be triggered as they should be; a workaround is to force rebuilding
-by touching appropriate files, e.g.
+The makefile variable @code{QUIET_BUILD} may be set to @code{1}
+for a less verbose build output, just like for building the
+programs.
-@example
-touch Documentation/extend.texi
-touch Documentation/*te??
-touch Documentation/snippets/*.te??
-@end example
+@node Building documentation without compiling
+@unnumberedsubsubsec Building documentation without compiling
-@node Building documentation without compiling LilyPond
-@unnumberedsubsubsec Building documentation without compiling LilyPond
The documentation can be built locally without compiling LilyPond
binary, if LilyPond is already installed on your system.
On MacOS X with macports, you should use this:
@verbatim
-export DYLD_LIBRARY_PATH=/opt/local/lib
+export DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib
exec /opt/local/bin/pngtopnm "$@"
@end verbatim
+@node Testing LilyPond binary
+@subsection Testing LilyPond binary
-@node Testing LilyPond
-@subsection Testing LilyPond
-
-@html
-<a name="testing"></a>
-@end html
LilyPond comes with an extensive suite that exercises the entire
-program. This suite can be used to automatically check the impact of a
-change. This is done as follows
-
-@example
-make test-baseline
-@emph{## apply your changes, compile}
-make check
-@end example
-
-This will leave an HTML page @file{out/test-results/index.html}. This
-page shows all the important differences that your change introduced,
-whether in the layout, MIDI, performance or error reporting.
-
-To rerun tests, use
-
-@example
-make test-redo @emph{## redo files differing from baseline}
-make test-clean @emph{## remove all test results}
-@end example
-
-@noindent
-and then run @code{make check} again.
+program. This suite can be used to test that the binary has
+been built correctly.
-For tracking memory usage as part of this test, you will need GUILE
-CVS; especially the following patch:
-@uref{http://lilypond.org/vc/gub.darcs/patches/guile-1.9-gcstats.patch}.
+The test suite can be executed with:
-For checking the coverage of the test suite, do the following
+@verbatim
+make test
+@end verbatim
-@example
-./scripts/auxiliar/build-coverage.sh
-@emph{# uncovered files, least covered first}
-./scripts/auxiliar/coverage.py --summary out-cov/*.cc
-@emph{# consecutive uncovered lines, longest first}
-./scripts/auxiliar/coverage.py --uncovered out-cov/*.cc
-@end example
+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
-@subsection 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.
-@unnumberedsubsubsec Bison 1.875
+@unnumberedsubsec Bison 1.875
There is a bug in bison-1.875: compilation fails with "parse error
before `goto'" in line 4922 due to a bug in bison. To fix, please
@end example
-@unnumberedsubsubsec Compiling on MacOS@tie{}X
+@unnumberedsubsec Compiling on MacOS@tie{}X
Here are special instructions for compiling under MacOS@tie{}X.
These instructions assume that dependencies are installed using
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
+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_LIBRARY_PATH=/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources:\
-/opt/local/lib:$DYLD_LIBRARY_PATH
+export DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib:$DYLD_FALLBACK_LIBRARY_PATH
@end example
-Now you must edit the generated @code{config.make} file. Change
+Now you must edit the generated @file{config.make} file. Change
@example
FLEXLEXER_FILE = /usr/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
+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
rm -rf urw-fonts-1.07pre44
@end example
-Now run the @code{./configure} script. To avoid complications with
+Now run the @code{./configure} script. To avoid complications with
automatic font detection, add
@example
@end example
-@unnumberedsubsubsec Solaris
+@unnumberedsubsec Solaris
Solaris7, ./configure
CONFIG_SHELL=/bin/bash bash -c ./configure
@end example
-@unnumberedsubsubsec FreeBSD
+@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}.
@end example
-@unnumberedsubsubsec International fonts
+@unnumberedsubsec International fonts
On Mac OS X, all fonts are installed by default. However, finding all
system fonts requires a bit of configuration; see
@end verbatim
-@unnumberedsubsubsec Using lilypond python libraries
+@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{.../usr/lib/lilypond/current/python} in the
+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
projects / lilypond.git / blobdiff