INSTALL - compiling and installing GNU LilyPond
***********************************************
-Table of Contents
-*****************
-INSTALL - compiling and installing GNU LilyPond
1 Compilation
1.1 Overview of compiling
1.2 Requirements
1.2.1 Requirements for running LilyPond
1.2.2 Requirements for compiling LilyPond
+ Fedora
+ Linux Mint
+ OpenSUSE
+ Ubuntu
+ Other
1.2.3 Requirements for building documentation
1.3 Getting the source code
- 1.4 Configuring `make'
- 1.4.1 Running `./autogen.sh'
- 1.4.2 Running `../configure'
+ 1.4 Configuring ‘make’
+ 1.4.1 Running ‘./autogen.sh’
+ 1.4.2 Running ‘../configure’
Configuration options
Checking build dependencies
Configuring target directories
1.5 Compiling LilyPond
- 1.5.1 Using `make'
- 1.5.2 Saving time with the `-j' option
+ 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
+ 1.5.4 Useful ‘make’ variables
1.6 Post-compilation options
1.6.1 Installing LilyPond from a local build
1.6.2 Generating documentation
- Documentation editor's edit/compile cycle
+ Documentation editor’s edit/compile cycle
Building documentation
Building a single document
- Saving time with `CPU_COUNT'
+ Saving time with ‘CPU_COUNT’
AJAX search
Installing documentation
Building documentation without compiling
1.6.3 Testing LilyPond binary
1.7 Problems
- Bison 1.875
Compiling on MacOS X
Solaris
FreeBSD
Using lilypond python libraries
1.8 Concurrent stable and development versions
1.9 Build system
-
-
1 Compilation
*************
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 *note
-Download: (lilypond-web)Download. page.
+(lilypond-web)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
+documentation. The documentation can be built using a Git repository in
+conjunction with a locally installed copy of the program. For more
information, see *note Building documentation without compiling::.
Attempts to compile LilyPond natively on Windows have been
-unsuccessful, though a workaround is available (see *note LilyDev:
-(lilypond-contributor)LilyDev.).
+unsuccessful, though a workaround is available (see *note
+(lilypond-contributor)LilyDev::).
1.2 Requirements
================
1.2.1 Requirements for running LilyPond
---------------------------------------
-Running LilyPond requires proper installation of the following software:
+This section contains the list of separate software packages that are
+required to run LilyPond.
+
+ • DejaVu fonts (http://www.dejavu-fonts.org/) These are normally
+ installed by default.
+
+ • FontConfig (http://www.fontconfig.org/) Use version 2.4.0 or newer.
- * DejaVu fonts (http://www.dejavu-fonts.org/) (normally installed by
- default)
+ • Freetype (http://www.freetype.org/) Use version 2.1.10 or newer.
- * FontConfig (http://www.fontconfig.org/) (2.4.0 or newer)
+ • Ghostscript (http://www.ghostscript.com) Use version 8.60 or newer.
- * Freetype (http://www.freetype.org/) (2.1.10 or newer)
+ • Guile (http://www.gnu.org/software/guile/guile.html) Use version
+ 1.8.8. Version 2.x of Guile is not currently supported.
- * Ghostscript (http://www.ghostscript.com) (8.60 or newer)
+ • Pango (http://www.pango.org/) User version 1.12 or newer.
- * Guile (http://www.gnu.org/software/guile/guile.html) (1.8.2 or
- newer)
+ • Python (http://www.python.org) Use version 2.4 or newer.
- * Pango (http://www.pango.org/) (1.12 or newer)
+ • International fonts. For example:
- * Python (http://www.python.org) (2.4 or newer)
+ Fedora:
+
+ fonts-arabic
+ fonts-hebrew
+ fonts-ja
+ fonts-xorg-truetype
+ taipeifonts
+ ttfonts-ja
+ ttfonts-zh_CN
+
+ Debian based distributions:
+
+ emacs-intl-fonts
+ fonts-ipafont-gothic
+ fonts-ipafont-mincho
+ xfonts-bolkhov-75dpi
+ xfonts-cronyx-75dpi
+ xfonts-cronyx-100dpi
+ xfonts-intl-.*
- International fonts are required to create music with international
-text or lyrics.
+ These are normally installed by default and are required only to
+ create music with international text or lyrics.
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:
+This section contains instructions on how to quickly and easily get all
+the software packages required to build LilyPond.
-Distribution Command
---------------------------------------------------------------------------
-Debian, Ubuntu `sudo apt-get build-dep lilypond'
-Fedora, RHEL `sudo yum-builddep lilypond'
-openSUSE, SLED `sudo zypper --build-deps-only
- source-install 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.
- * Everything listed in *note Requirements for running LilyPond::
+Fedora
+......
- * Development packages for the above items (which should include
- header files and libraries).
+The following instructions were tested on ‘Fedora’ versions 22 & 23 and
+will download all the software required to both compile LilyPond and
+build the documentation.
- Red Hat Fedora:
+ • Download and install all the LilyPond build-dependencies
+ (approximately 700MB);
- guile-devel-VERSION
- fontconfig-devel-VERSION
- freetype-devel-VERSION
- pango-devel-VERSION
- python-devel-VERSION
+ sudo dnf builddep lilypond --nogpgcheck
- Debian GNU/Linux:
+ • Download and install additional ‘build’ tools required for
+ compiling;
- guile-VERSION-dev
- libfontconfig1-dev
- libfreetype6-dev
- libpango1.0-dev
- pythonVERSION-dev
+ sudo dnf install autoconf gcc-c++
- * Flex (http://flex.sourceforge.net/)
+ • Download ‘texi2html 1.82’ directly from:
+ <http://download.savannah.gnu.org/releases/texi2html/texi2html-1.82.tar.gz>;
- * FontForge (http://fontforge.sf.net/) (20060125 or newer; 20100501
- or newer is recommended; must be compiled with `--enable-double'.
- Failure to do so can lead to poor intersection calculations and
- poorly-rendered glyphs.)
+ ‘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;
- * GNU Bison (http://www.gnu.org/software/bison/)
+ ./configure
+ make
+ sudo make install
- * GNU Compiler Collection (http://gcc.gnu.org/) (3.4 or newer, 4.X
- recommended)
+ This should install ‘texi2html 1.82’ into ‘/usr/local/bin’, which
+ will normally take priority over ‘/usr/bin’ where the later,
+ pre-installed versions gets put. Now verify that your operating
+ system is able to see the correct version of ‘texi2html’.
- * GNU gettext (http://www.gnu.org/software/gettext/gettext.html)
- (0.17 or newer)
+ texi2html --version
- * GNU Make (http://www.gnu.org/software/make/) (3.78 or newer)
+ • Although not ‘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 ‘git’.
- * MetaFont (http://metafont.tutorial.free.fr/) (mf-nowin, mf, mfw or
- mfont binaries), usually packaged with TeX
- (http://www.latex-project.org/ftp.html).
+ sudo dnf install git
+
+ Also see *note (lilypond-contributor)Starting with Git::.
+
+ • To use the ‘lily-git.tcl’ GUI;
+
+ sudo dnf install tk
+
+ See *note (lilypond-contributor)lily-git::.
+
+ Note: By default, when building LilyPond’s documentation,
+ ‘pdfTeX’ is be used. However ligatures (fi, fl, ff etc.) may
+ not be printed in the PDF output. In this case XeTeX can be
+ used instead. Download and install the ‘texlive-xetex’
+ package.
+
+ sudo dnf install texlive-xetex
+
+ The scripts used to build the LilyPond documentation will use
+ ‘XeTex’ instead of ‘pdfTex’ to generate the PDF documents if
+ it is available. No additional configuration is required.
+
+Linux Mint
+..........
+
+The following instructions were tested on ‘Linux Mint 17.1’ and ‘LMDE -
+Betsy’ and will download all the software required to both compile
+LilyPond and build the documentation..
+
+ • Enable the _sources_ repository;
+
+ 1. Using the _Software Sources_ GUI (located under
+ _Administration_).
+
+ 2. Select _Official Repositories_.
+
+ 3. Check the _Enable source code repositories_ box under the
+ _Source Code_ section.
+
+ 4. Click the _Update the cache_ button and when it has completed,
+ close the _Software Sources_ GUI.
+
+ • Download and install all the LilyPond build-dependencies
+ (approximately 200MB);
+
+ sudo apt-get build-dep lilypond
+
+ • Download and install additional ‘build’ tools required for
+ compiling;
+
+ sudo apt-get install autoconf fonts-texgyre texlive-lang-cyrillic
+
+ • Although not ‘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 ‘git’.
+
+ sudo apt-get install git
+
+ Also see *note (lilypond-contributor)Starting with Git::.
+
+ • To use the ‘lily-git.tcl’ GUI;
+
+ sudo apt-get install tk
+
+ Also see *note (lilypond-contributor)lily-git::.
+
+ Note: By default, when building LilyPond’s documentation,
+ ‘pdfTeX’ is be used. However ligatures (fi, fl, ff etc.) may
+ not be printed in the PDF output. In this case XeTeX can be
+ used instead. Download and install the ‘texlive-xetex’
+ package.
+
+ sudo apt-get install texlive-xetex
+
+ The scripts used to build the LilyPond documentation will use
+ ‘XeTex’ instead of ‘pdfTex’ to generate the PDF documents if
+ it is available. No additional configuration is required.
+
+OpenSUSE
+........
+
+The following instructions were tested on ‘OpenSUSE 13.2’ and will
+download all the software required to both compile LilyPond and build
+the documentation.
+
+ • Add the _sources_ repository;
+
+ sudo zypper addrepo -f \
+ "http://download.opensuse.org/source/distribution/13.2/repo/oss/" sources
+
+ • Download and install all the LilyPond build-dependencies
+ (approximately 680MB);
+
+ sudo zypper source-install lilypond
+
+ • Download and install additional ‘build’ tools required for
+ compiling;
+
+ sudo zypper install make
+
+ • Although not ‘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 ‘git’.
+
+ sudo zypper install git
+
+ Also see *note (lilypond-contributor)Starting with Git::.
+
+ • To use the ‘lily-git.tcl’ GUI;
+
+ sudo zypper install tk
+
+ Also see *note (lilypond-contributor)lily-git::.
+
+ Note: By default, when building LilyPond’s documentation,
+ ‘pdfTeX’ is be used. However ligatures (fi, fl, ff etc.) may
+ not be printed in the PDF output. In this case XeTeX can be
+ used instead. Download and install the ‘texlive-xetex’
+ package.
+
+ sudo zypper install texlive-xetex
+
+ The scripts used to build the LilyPond documentation will use
+ ‘XeTex’ instead of ‘pdfTex’ to generate the PDF documents if
+ it is available. No additional configuration is required.
+
+Ubuntu
+......
- * MetaPost (http://cm.bell-labs.com/who/hobby/MetaPost.html) (mpost
- binary), usually packaged with TeX
+The following commands were tested on Ubuntu versions ‘14.04 LTS’,
+‘14.10’ and ‘15.04’ and will download all the software required to both
+compile LilyPond and build the documentation.
+
+ • Download and install all the LilyPond build-dependencies
+ (approximately 200MB);
+
+ sudo apt-get build-dep lilypond
+
+ • Download and install additional ‘build’ tools required for
+ compiling;
+
+ sudo apt-get install autoconf fonts-texgyre texlive-lang-cyrillic
+
+ • Although not ‘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 ‘git’.
+
+ sudo apt-get install git
+
+ Also see *note (lilypond-contributor)Starting with Git::.
+
+ • To use the ‘lily-git.tcl’ GUI;
+
+ sudo apt-get install tk
+
+ Also see *note (lilypond-contributor)lily-git::.
+
+ Note: By default, when building LilyPond’s documentation,
+ ‘pdfTeX’ is be used. However ligatures (fi, fl, ff etc.) may
+ not be printed in the PDF output. In this case XeTeX can be
+ used instead. Download and install the ‘texlive-xetex’
+ package.
+
+ sudo apt-get install texlive-xetex
+
+ The scripts used to build the LilyPond documentation will use
+ ‘XeTex’ instead of ‘pdfTex’ to generate the PDF documents if
+ it is available. No additional configuration is required.
+
+Other
+.....
+
+The following individual software packages are required just to compile
+LilyPond.
+
+ • GNU Autoconf (http://www.gnu.org/software/autoconf)
+
+ • GNU Bison (http://www.gnu.org/software/bison/)
+
+ Use version ‘2.0’ or newer.
+
+ • GNU Compiler Collection (http://gcc.gnu.org/)
+
+ Use version ‘3.4’ or newer (‘4.x’ recommended).
+
+ • Flex (http://flex.sourceforge.net/)
+
+ • FontForge (http://fontforge.sf.net/)
+
+ Use version ‘20060125’ or newer (we recommend using at least
+ ‘20100501’); it must also be compiled with the ‘--enable-double’
+ switch, else this can lead to inaccurate intersection calculations
+ which end up with poorly-rendered glyphs in the output.
+
+ • GNU gettext (http://www.gnu.org/software/gettext/gettext.html)
+
+ Use version ‘0.17’ or newer.
+
+ • GNU Make (http://www.gnu.org/software/make/)
+
+ Use version ‘3.78’ or newer.
+
+ • MetaFont (http://metafont.tutorial.free.fr/)
+
+ The ‘mf-nowin’, ‘mf’, ‘mfw’ or ‘mfont’ binaries are usually
+ packaged along with TeX (http://www.latex-project.org/ftp.html).
+
+ • MetaPost (http://cm.bell-labs.com/who/hobby/MetaPost.html)
+
+ The ‘mpost’ binary is also usually packaged with TeX
(http://www.latex-project.org/ftp.html).
- * Perl (http://www.perl.org/)
+ • Perl (http://www.perl.org/)
+
+ • Texinfo (http://www.gnu.org/software/texinfo/)
+
+ Use version ‘4.11’ or newer.
- * Texinfo (http://www.gnu.org/software/texinfo/) (4.11 or newer)
+ • Type 1 utilities (http://www.lcdf.org/~eddietwo/type/#t1utils)
- * Type 1 utilities (http://www.lcdf.org/~eddietwo/type/#t1utils)
- (1.33 or newer recommended)
+ Use version ‘1.33’ or newer.
+
+ • Cyrillic fonts (https://www.ctan.org/pkg/cyrillic?lang=en)
+
+ Often packaged in repositories as ‘texlive-lang-cyrillic’.
+
+ • TeX Gyre ‘OTF’ font packages. As of LilyPond version ‘2.19.26’,
+ the previous default serif, san serif and monospace fonts now use
+ Tex Gyre’s _Schola_, _Heros_ and _Cursor_ fonts respectively. Also
+ See *note (lilypond-notation)Fonts::.
+
+ Some distributions do not always provide ‘OTF’ font files in the
+ Tex Gyre packages from their repositories. Use the command
+ ‘fc-list | grep texgyre’ to list the fonts available to your system
+ and check that the appropriate ‘*.otf’ files are reported. If they
+ are not then download and manually extract the ‘OTF’ files to
+ either your local ‘~/.fonts/’ directory or use the ‘configure’
+ command and the ‘--with-texgyre-dir=/path_to_otf_files/’ option.
+
+ The following font families are required:
+
+ Schola (http://www.gust.org.pl/projects/e-foundry/tex-gyre/schola),
+ Heros (http://www.gust.org.pl/projects/e-foundry/tex-gyre/heros)
+ and Cursor
+ (http://www.gust.org.pl/projects/e-foundry/tex-gyre/cursor).
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:
+The entire set of documentation for the most current build of LilyPond
+is available online at
+<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.
- * Everything listed in *note Requirements for compiling LilyPond::
+ Note: If the instructions for one of the previously listed
+ Linux in the previous section (*note
+ (lilypond-contributor)Requirements for compiling LilyPond::)
+ have been used, then the following can be ignored as the
+ software should already be installed.
- * ImageMagick (http://www.imagemagick.org/)
+ • Everything listed in *note Requirements for compiling LilyPond::
- * Netpbm (http://netpbm.sourceforge.net/)
+ • ImageMagick (http://www.imagemagick.org/)
- * gzip (http://gzip.org/)
+ • Netpbm (http://netpbm.sourceforge.net/)
- * rsync (http://rsync.samba.org/)
+ • gzip (http://gzip.org/)
- * Texi2HTML (http://www.nongnu.org/texi2html/) (1.82)
+ • rsync (http://rsync.samba.org/)
- * International fonts
+ • Texi2HTML (http://www.nongnu.org/texi2html/)
- Red Hat Fedora:
+ Use version ‘1.82’. Later versions will not work.
- fonts-arabic
- fonts-hebrew
- fonts-ja
- fonts-xorg-truetype
- taipeifonts
- ttfonts-ja
- ttfonts-zh_CN
+ Download ‘texi2html 1.82’ directly from:
+ <http://download.savannah.gnu.org/releases/texi2html/texi2html-1.82.tar.gz>;
- Debian GNU/Linux:
+ Extract the files into an appropriate location and then run the
+ commands;
- emacs-intl-fonts
- ttf-kochi-gothic
- ttf-kochi-mincho
- xfonts-bolkhov-75dpi
- xfonts-cronyx-75dpi
- xfonts-cronyx-100dpi
- xfonts-intl-.*
+ ./configure
+ make
+ sudo make install
+
+ Now verify that your operating system is able to see the correct
+ version of ‘texi2html’.
+
+ texi2html --version
+
+ • Fonts required to build the documentation in addition to those
+ required to run LilyPond:
+
+ gsfonts
+ fonts-linuxlibertine
+ fonts-liberation
+ fonts-dejavu
+ fonts-freefont-otf
+ ttf-bitstream-vera
+ texlive-fonts-recommended
+ ttf-xfree86-nonfree
+
+ Note: By default, when building LilyPond’s documentation,
+ ‘pdfTeX’ is be used. However ligatures (fi, fl, ff etc.) may
+ not be printed in the PDF output. In this case XeTeX can be
+ used instead. Download and install the ‘texlive-xetex’
+ package. The scripts used to build the LilyPond documentation
+ will use ‘XeTex’ instead of ‘pdfTex’ to generate the PDF
+ documents if it is available. No additional configuration is
+ required.
1.3 Getting the source code
===========================
In general, developers compile LilyPond from within a local Git
repository. Setting up a local Git repository is explained in *note
-Starting with Git: (lilypond-contributor)Starting with Git.
+(lilypond-contributor)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 *note
-Source: (lilypond-web)Source. page.
+(lilypond-web)Source:: page.
The latest source code snapshot
(http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=snapshot) is also
All tagged releases (including legacy stable versions and the most
recent development release) are available here:
- `http://download.linuxaudio.org/lilypond/source/'
+ <http://download.linuxaudio.org/lilypond/source/>
- Download the tarball to your `~/src/' directory, or some other
+ 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
+ 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
+‘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
-(http://www.7-zip.org) to extract the tarball.
+ Windows users wanting to look at the source code may have to download
+and install the free-software 7zip archiver (http://www.7-zip.org) to
+extract the tarball.
-1.4 Configuring `make'
+1.4 Configuring ‘make’
======================
-1.4.1 Running `./autogen.sh'
+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'.
+<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.
+configuration, such as ‘configure’, ‘README.txt’, etc.
Next, create the build directory with:
We heavily recommend building lilypond inside a separate directory
with this method.
-1.4.2 Running `../configure'
+1.4.2 Running ‘../configure’
----------------------------
Configuration options
.....................
- Note: make sure that you are in the `build/' subdirectory of
+ 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:
+ The ‘../configure’ command (generated by ‘./autogen.sh’) provides
+many options for configuring ‘make’. To see them all, run:
../configure --help
Checking build dependencies
...........................
- Note: make sure that you are in the `build/' subdirectory of
+ 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:
+ 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:
+ If any build dependency is missing, ‘../configure’ will return with:
ERROR: Please install required programs: FOO
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
+ 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 *note Requirements for building
Configuring target directories
..............................
- Note: make sure that you are in the `build/' subdirectory of
+ 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':
+ 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''.
+ 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':
+ 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.
+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.
+ 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.
+‘../configure --help’ for more information.
If you encounter any problems, please see *note Problems::.
1.5 Compiling LilyPond
======================
-1.5.1 Using `make'
+1.5.1 Using ‘make’
------------------
- Note: make sure that you are in the `build/' subdirectory of
+ Note: make sure that you are in the ‘build/’ subdirectory of
your source tree.
-LilyPond is compiled with the `make' command. Assuming `make' is
+ 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,
+ ‘make’ is short for ‘make all’. To view a list of ‘make’ targets,
run:
make help
- TODO: Describe what `make' actually does.
-
+ TODO: Describe what ‘make’ actually does.
See also
........
-
-
- *note Generating documentation:: provides more info on the `make'
+ *note Generating documentation:: provides more info on the ‘make’
targets used to build the LilyPond documentation.
-1.5.2 Saving time with the `-j' option
+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:
+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.
+ 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
+ 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.
+case, running ‘make’ without the ‘-j’ is advised.
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
+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
--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':
+ 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
........
-
-
*note Installing LilyPond from a local build::
-1.5.4 Useful `make' variables
+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
+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.
1.6 Post-compilation options
1.6.1 Installing LilyPond from a local build
--------------------------------------------
-If you configured `make' to install your local build in a directory
+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
+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':
+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
su -c 'make install'
- If you don't have superuser privileges, then you need to configure
+ 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 *note Configuring target directories::.
1.6.2 Generating documentation
------------------------------
-Documentation editor's edit/compile cycle
+Documentation editor’s edit/compile cycle
.........................................
- * Initial documentation build:
+ • Initial documentation build:
make [-jX]
make [-jX CPU_COUNT=X] doc _## can take an hour or more_
make [-jX CPU_COUNT=X] doc-stage-1 _## to build only PDF documentation_
- * Edit/compile cycle:
+ • Edit/compile cycle:
_## edit source files, then..._
_## for finding Texinfo errors._
make [-jX CPU_COUNT=X] doc _## usually faster than initial build._
- * Reset:
+ • Reset:
It is generally possible to remove the compiled documentation from
- your system with `make doc-clean', but this method is not 100%
+ your system with ‘make 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 `build/' directory, and
+ system, we recommend that you delete your ‘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.
-
+ takes much longer than the non-documentation compile, this does not
+ increase the overall time by a great deal.
Building documentation
......................
-After a successful compile (using `make'), the documentation can be
+After a successful compile (using ‘make’), the documentation can be
built by issuing:
make doc
make doc-stage-1
- Note: The first time you run `make doc', the process can
+ 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
+ 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'
+ 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.
+‘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 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
+ ‘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 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:
+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'
Building a single document
..........................
-It's possible to build a single document. For example, to rebuild only
-`contributor.pdf', do the following:
+It’s possible to build a single document. For example, to rebuild only
+‘contributor.pdf’, do the following:
cd build/
cd Documentation/
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.
+‘contributor.pdf’, for example, takes a matter of seconds.
-Saving time with `CPU_COUNT'
+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:
+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.
+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.
AJAX search
...........
make install-info
-Note that to get the images in Info documentation, `install-doc' target
+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.
+‘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
+‘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
+and both ‘offline’ and ‘online’ targets can be generated by issuing
make WEB_TARGETS="offline online" doc
make help
from every directory in the build tree. Most targets for documentation
-maintenance are available from `Documentation/'; for more information,
-see *note Documentation work: (lilypond-contributor)Documentation work.
+maintenance are available from ‘Documentation/’; for more information,
+see *note (lilypond-contributor)Documentation work::.
- The makefile variable `QUIET_BUILD' may be set to `1' for a less
+ The makefile variable ‘QUIET_BUILD’ may be set to ‘1’ for a less
verbose build output, just like for building the programs.
Building documentation without compiling
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
+ 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
+ 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
Known issues and warnings
.........................
-You may also need to create a script for `pngtopnm' and `pnmtopng'. On
+You may also need to create a script for ‘pngtopnm’ and ‘pnmtopng’. On
GNU/Linux, I use this:
export LD_LIBRARY_PATH=/usr/lib
been verified.
More information on the regression test suite is found at *note
-Regression tests: (lilypond-contributor)Regression tests.
+(lilypond-contributor)Regression tests::.
1.7 Problems
============
-For help and questions use <lilypond-user@gnu.org>. Send bug reports
-to <bug-lilypond@gnu.org>.
+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.
-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
-
Compiling on MacOS X
--------------------
-Here are special instructions for compiling under MacOS X. These
+Here are special instructions for compiling under MacOS X. These
instructions assume that dependencies are installed using MacPorts.
(http://www.macports.org/) 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.
+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
+ Now you must edit the generated ‘config.make’ file. Change
FLEXLEXER_FILE = /usr/include/FlexLexer.h
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
+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:
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
+ Now run the ‘./configure’ script. To avoid complications with
automatic font detection, add
- --with-ncsb-dir=/opt/local/share/ghostscript/fonts
+ --with-fonts-dir=/opt/local/share/ghostscript/fonts
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
+ ‘./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
FreeBSD
-------
-To use system fonts, dejaview must be installed. With the default
-port, the fonts are installed in `usr/X11R6/lib/X11/fonts/dejavu'.
+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
+ 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>
On Mac OS X, all fonts are installed by default. However, finding all
system fonts requires a bit of configuration; see this post
(http://lists.gnu.org/archive/html/lilypond-user/2007-03/msg00472.html)
-on the `lilypond-user' mailing list.
+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
Debian GNU/Linux
apt-get install emacs-intl-fonts xfonts-intl-.* \
- ttf-kochi-gothic ttf-kochi-mincho \
+ fonts-ipafont-gothic fonts-ipafont-mincho \
xfonts-bolkhov-75dpi xfonts-cronyx-100dpi xfonts-cronyx-75dpi
Using lilypond python libraries
-------------------------------
-If you want to use lilypond's python libraries (either running certain
+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
+‘PYTHONPATH’ to ‘python/out’ in your build directory, or
+‘.../usr/lib/lilypond/current/python’ in the installation directory
structure.
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
+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:
+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'
+ 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.
+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:
+ 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':
+‘$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:
+ Save it as ‘Lilypond’ (with a capital L to distinguish it from the
+stable ‘lilypond’), and make it executable:
chmod +x Lilypond
Version-specific texinfo macros
-------------------------------
- * made with `scripts/build/create-version-itexi.py' and
- `scripts/build/create-weblinks-itexi.py'
+ • made with ‘scripts/build/create-version-itexi.py’ and
+ ‘scripts/build/create-weblinks-itexi.py’
- * used extensively in the `WEBSITE_ONLY_BUILD' version of the
- website (made with `website.make', used on lilypond.org)
+ • used extensively in the ‘WEBSITE_ONLY_BUILD’ version of the website
+ (made with ‘website.make’, used on lilypond.org)
- * not (?) used in the main docs?
+ • not (?) used in the main docs?
- * the numbers in VERSION file: MINOR_VERSION should be 1 more than
+ • the numbers in VERSION file: MINOR_VERSION should be 1 more than
the last release, VERSION_DEVEL should be the last *online*
release. Yes, VERSION_DEVEL is less than VERSION.
-