[Top][Contents][Index][ ? ]

INSTALL - compiling and installing GNU LilyPond

1. Compilation  
[ << Top ][Top][Contents][Index][ ? ][  >> ]
[ < Top ][  Up : Top ][]

1. Compilation

1.1 Overview of compiling  
1.2 Requirements  
1.3 Getting the source code  
1.4 Configuring make  
1.5 Compiling LilyPond  
1.6 Post-compilation options  
1.7 Problems  
1.8 Concurrent stable and development versions  
1.9 Build system  
[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Compilation ][  Up : Compilation ][]

1.1 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 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 Building documentation without compiling.

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

[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Overview of compiling ][  Up : Compilation ][]

1.2 Requirements

1.2.1 Requirements for running LilyPond  
1.2.2 Requirements for compiling LilyPond  
1.2.3 Requirements for building documentation  
[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Requirements ][  Up : Requirements ][]

1.2.1 Requirements for running LilyPond

Running LilyPond requires proper installation of the following software:

International fonts are required to create music with international text or lyrics.

[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Requirements for running LilyPond ][  Up : Requirements ][]

1.2.2 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:

DistributionCommand
Debian, Ubuntusudo apt-get build-dep lilypond
Fedora, RHELsudo yum-builddep lilypond
openSUSE, SLEDsudo zypper --build-deps-only source-install lilypond
[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Requirements for compiling LilyPond ][  Up : Requirements ][]

1.2.3 Requirements for building documentation

You can view the documentation online at http://www.lilypond.org/doc/, but you can also build it locally. This process requires some additional tools and packages:

[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Requirements for building documentation ][  Up : Compilation ][]

1.3 Getting the source code

Downloading the Git repository

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

Downloading a source tarball

Packagers are encouraged to use source tarballs for compiling.

The tarball for the latest stable release is available on the Source page.

The latest source code snapshot is also available as a tarball from the GNU Savannah Git server.

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

http://download.linuxaudio.org/lilypond/source/

Download the tarball to your ‘~/src/’ directory, or some other appropriate place.

Note: Be careful where you unpack the tarball! Any subdirectories of the current folder named ‘lilypond/’ or ‘lilypond-x.y.z/’ (where 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: 

tar -xzf lilypond-x.y.z.tar.gz

This creates a subdirectory within the current directory called ‘lilypond-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 7zip archiver to extract the tarball.

[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Getting the source code ][  Up : Compilation ][]

1.4 Configuring make

1.4.1 Running ./autogen.sh  
1.4.2 Running ../configure  
[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Configuring make ][  Up : Configuring make ][]

1.4.1 Running ./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 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: 

./autogen.sh --noconfigure

This will generate a number of files and directories to aid configuration, such as ‘configure’, ‘README.txt’, etc.

Next, create the build directory with: 

mkdir build/
cd build/

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

[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Running ./autogen.sh ][  Up : Configuring make ][]

1.4.2 Running ../configure

Configuration options  
Checking build dependencies  
Configuring target directories  
[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Running ../configure ][  Up : Running ../configure ][]

Configuration options

Note: make sure that you are in the ‘build/’ subdirectory of your source tree.

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

../configure --help
[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Configuration options ][  Up : Running ../configure ][]

Checking build dependencies

Note: make sure that you are in the ‘build/’ subdirectory of your source tree.

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

../configure

If any build dependency is missing, ../configure will return with: 

ERROR: Please install required programs:  foo

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

WARNING: Please consider installing optional programs:  bar

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

Note: ../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 Requirements for building documentation.

[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Checking build dependencies ][  Up : Running ../configure ][]

Configuring target directories

Note: make sure that you are in the ‘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 ../configure --help:

By default, ‘make install’ will install all the files in ‘/usr/local/bin’, ‘/usr/local/lib’ etc. You can specify an installation prefix other than ‘/usr/local’ using ‘‘--prefix’’, for instance ‘‘--prefix=$HOME’’.

A typical installation prefix is ‘$HOME/usr’: 

../configure --prefix=$HOME/usr

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—make 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 lilypond command installed by this process will be ‘prefix/bin/lilypond’; you may want to add ‘prefix/bin/’ to your $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 ../configure --help for more information.

If you encounter any problems, please see Problems.

[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Configuring target directories ][  Up : Compilation ][]

1.5 Compiling LilyPond

1.5.1 Using make  
1.5.2 Saving time with the ‘-j’ option  
1.5.3 Compiling for multiple platforms  
1.5.4 Useful make variables  
[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Compiling LilyPond ][  Up : Compiling LilyPond ][]

1.5.1 Using make

Note: make sure that you are in the ‘build/’ subdirectory of your source tree.

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

make

‘make’ is short for ‘make all’. To view a list of make targets, run: 

make help

TODO: Describe what make actually does.

See also

Generating documentation provides more info on the make targets used to build the LilyPond documentation.

[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Using make ][  Up : Compiling LilyPond ][]

1.5.2 Saving time with the ‘-j’ option

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

make -j3

If you get errors using the ‘-j’ option, and ‘make’ succeeds without it, try lowering the X value.

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

[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Saving time with the -j option ][  Up : Compiling LilyPond ][]

1.5.3 Compiling for multiple platforms

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

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

and for the profiling version, specify a different configuration 

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

If you wish to install a copy of the build with profiling, don’t forget to use conf=CONF when issuing make install: 

make conf=prof install

See also

Installing LilyPond from a local build

[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Compiling for multiple platforms ][  Up : Compiling LilyPond ][]

1.5.4 Useful make variables

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

[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Useful make variables ][  Up : Compilation ][]

1.6 Post-compilation options

1.6.1 Installing LilyPond from a local build  
1.6.2 Generating documentation  
1.6.3 Testing LilyPond binary  
[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Post-compilation options ][  Up : Post-compilation options ][]

1.6.1 Installing LilyPond from a local build

If you configured 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 make, you can install the program in your target directory by running: 

make install

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

sudo make install

or… 

su -c 'make install'

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 Configuring target directories.

[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Installing LilyPond from a local build ][  Up : Post-compilation options ][]

1.6.2 Generating documentation

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  
[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Generating documentation ][  Up : Generating documentation ][]

Documentation editor’s edit/compile cycle

[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Documentation editor's edit/compile cycle ][  Up : Generating documentation ][]

Building documentation

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

make doc

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

make doc-stage-1

Note: The first time you run make doc, the process can easily take an hour or more with not much output on the command line.

After this initial build, make 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 make doc succeeds, the HTML documentation tree is available in ‘out-www/offline-root/’, and can be browsed locally. Various portions of the documentation can be found by looking in ‘out/’ and ‘out-www’ subdirectories in other places in the source tree, but these are only portions of the docs. Please do not complain about anything which is broken in those places; the only complete set of documentation is in ‘out-www/offline-root/’ from the top of the source tree.

make 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 make doc-clean. To remove all the logfiles generated by the compilation process, use: 

make log-clean

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

make LANGS='' doc

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: 

make LANGS='de fr' doc

Note that this will also compile the English version.

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

make info

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: 

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

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

[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Building documentation ][  Up : Generating documentation ][]

Building a single document

It’s possible to build a single document. For example, to rebuild only ‘contributor.pdf’, do the following: 

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

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

[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Building a single document ][  Up : Generating documentation ][]

Saving time with 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 lilypond-book instances, so the ‘-j’ make option does not significantly speed up the build process. To help speed it up, the makefile variable ‘CPU_COUNT’ may be set in ‘local.make’ or on the command line to the number of .ly files that LilyPond should process simultaneously, e.g. on a bi-processor or dual core machine: 

make -j3 CPU_COUNT=3 doc

The recommended value of ‘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 ‘-j’ option that pose problems with ‘make’ are less likely to pose problems with ‘make doc’ (this applies to both ‘-j’ and ‘CPU_COUNT’). For example, with a quad-core processor, it is possible for ‘make -j5 CPU_COUNT=5 doc’ to work consistently even if ‘make -j5’ rarely succeeds.

[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Saving time with CPU_COUNT ][  Up : Generating documentation ][]

AJAX search

To build the documentation with interactive searching, use: 

make doc AJAX_SEARCH=1

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

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

[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < AJAX search ][  Up : Generating documentation ][]

Installing documentation

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

make install-doc

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: 

make install-info

Note that to get the images in Info documentation, install-doc target creates symbolic links to HTML and PDF installed documentation tree in ‘prefix/share/info’, in order to save disk space, whereas install-info copies images in ‘prefix/share/info’ subdirectories.

It is possible to build a documentation tree in ‘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 

make WEB_TARGETS=online doc

and both ‘offline’ and ‘online’ targets can be generated by issuing 

make WEB_TARGETS="offline online" doc

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

make help

from every directory in the build tree. Most targets for documentation maintenance are available from ‘Documentation/’; for more information, see Documentation work.

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

[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Installing documentation ][  Up : Generating documentation ][]

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 

./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

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 ‘input/*’ stuff (i.e. mostly regression tests): change directory, for example to ‘Documentation/’, issue make doc, which will build documentation in a subdirectory ‘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 

make out=www WWW-post

Known issues and warnings

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

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

On MacOS X with fink, I use this: 

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

On MacOS X with macports, you should use this: 

export DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib
exec /opt/local/bin/pngtopnm "$@"
[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Building documentation without compiling ][  Up : Post-compilation options ][]

1.6.3 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: 

make test

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

More information on the regression test suite is found at Regression tests.

[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Testing LilyPond binary ][  Up : Compilation ][]

1.7 Problems

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

Bugs that are not fault of LilyPond are documented here.

[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Problems ][  Up : Problems ][]

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 recompile bison 1.875 with the following fix 

$ cd lily; make out/parser.cc
$ vi +4919 out/parser.cc
# append a semicolon to the line containing "__attribute__ ((__unused__))
# save
$ make
[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ <  ][  Up : Problems ][]

Compiling on MacOS X

Here are special instructions for compiling under MacOS X. These instructions assume that dependencies are installed using 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 ~/.profile by default. You should create this file if it does not exist. 

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

Now you must edit the generated ‘config.make’ file. Change 

FLEXLEXER_FILE = /usr/include/FlexLexer.h

to: 

FLEXLEXER_FILE = /opt/local/include/FlexLexer.h

At this point, you should verify that you have the appropriate fonts installed with your ghostscript installation. Check 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: 

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

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

--with-ncsb-dir=/opt/local/share/ghostscript/fonts
[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ <  ][  Up : Problems ][]

Solaris

Solaris7, ./configure

‘./configure’ needs a POSIX compliant shell. On Solaris7, ‘/bin/sh’ is not yet POSIX compliant, but ‘/bin/ksh’ or bash is. Run configure like 

CONFIG_SHELL=/bin/ksh ksh -c ./configure

or 

CONFIG_SHELL=/bin/bash bash -c ./configure
[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ <  ][  Up : Problems ][]

FreeBSD

To use system fonts, dejaview must be installed. With the default port, the fonts are installed in ‘usr/X11R6/lib/X11/fonts/dejavu’.

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

<dir>/usr/X11R6/lib/X11/fonts</dir>
[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ <  ][  Up : Problems ][]

International fonts

On Mac OS X, all fonts are installed by default. However, finding all system fonts requires a bit of configuration; see this post on the 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: 

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-.* \
        ttf-kochi-gothic ttf-kochi-mincho \
        xfonts-bolkhov-75dpi xfonts-cronyx-100dpi xfonts-cronyx-75dpi
[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ <  ][  Up : Problems ][]

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 PYTHONPATH to ‘python/out’ in your build directory, or ‘…/usr/lib/lilypond/current/python’ in the installation directory structure.

[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ <  ][  Up : Compilation ][]

1.8 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 make all from the top directory of the Lilypond source files, there will be a binary called lilypond in the out directory: 

<path to>/lilypond/out/bin/lilypond

This binary can be run without actually doing the make install command. The advantage to this is that you can have all of the latest changes available after pulling from git and running 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: 

lilypond foobar.ly

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 $PATH: 

exec <path to>/lilypond/out/bin/lilypond "$@"

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

chmod +x Lilypond

Then you can invoke the development version this way: 

Lilypond foobar.ly

TODO: ADD

- other compilation tricks for developers

[ << Compilation ][Top][Contents][Index][ ? ][  >> ]
[ < Concurrent stable and development versions ][  Up : Compilation ][  > ]

1.9 Build system

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

Version-specific texinfo macros

[Top][Contents][Index][ ? ]

Table of Contents

[Top][Contents][Index][ ? ]

About This Document

This document was generated by Don Armstrong on November 16, 2014 using texi2html 1.82.

The buttons in the navigation panels have the following meaning:

Button Name Go to From 1.2.3 go to
[]
[ << ] FastBack Beginning of this chapter or previous chapter 1
[]
[Top] Top Cover (top) of document  
[Contents] Contents Table of contents  
[Index] Index Index  
[ ? ] About About (help)  
[]
[ >> ] FastForward Next chapter 2
[]
[]
[ < ] Back Previous section in reading order 1.2.2
[]
[ Up ] Up Up section 1.2
[]
[ > ] Forward Next section in reading order 1.2.4

where the Example assumes that the current position is at Subsubsection One-Two-Three of a document of the following structure:

This page is for LilyPond-2.18.2 (stable-branch).

We welcome your aid; please help us by reporting errors to our bug list.

<< Back to Documentation Index

INSTALL - compiling and installing GNU LilyPond v2.18.2 (stable-branch).