[Top][Contents][Index][ ? ] |
INSTALL - compiling and installing GNU LilyPond
[ << Top ] | [Top][Contents][Index][ ? ] | [ Requirements >> ] | ||
[ < Top ] | [ Up : Top ] | [ Requirements > ] |
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 Using a Virtual Machine to Compile LilyPond).
[ << Overview of compiling ] | [Top][Contents][Index][ ? ] | [ Getting the source code >> ] | ||
[ < Overview of compiling ] | [ Up : Top ] | [ Requirements for running LilyPond > ] |
2. Requirements
2.1 Requirements for running LilyPond | ||
2.2 Requirements for compiling LilyPond | ||
2.3 Requirements for building documentation |
[ << Requirements ] | [Top][Contents][Index][ ? ] | [ Getting the source code >> ] | ||
[ < Requirements ] | [ Up : Requirements ] | [ Requirements for compiling LilyPond > ] |
2.1 Requirements for running LilyPond
Running LilyPond requires proper installation of the following software:
- DejaVu fonts (normally installed by default)
- FontConfig (2.4.0 or newer)
- Freetype (2.1.10 or newer)
- Ghostscript (8.60 or newer)
- Guile (1.8.2 or newer)
- Pango (1.12 or newer)
- Python (2.4 or newer)
International fonts are required to create music with international text or lyrics.
[ << Requirements ] | [Top][Contents][Index][ ? ] | [ Getting the source code >> ] | ||
[ < Requirements for running LilyPond ] | [ Up : Requirements ] | [ Requirements for building documentation > ] |
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:
Distribution | Command |
---|---|
Debian, Ubuntu | |
Fedora, RHEL | |
openSUSE, SLED | |
- Everything listed in Requirements for running LilyPond
- Development packages for the above items (which should
include header files and libraries).
Red Hat Fedora:
guile-devel-version fontconfig-devel-version freetype-devel-version pango-devel-version python-devel-version
Debian GNU/Linux:
guile-version-dev libfontconfig1-dev libfreetype6-dev libpango1.0-dev pythonversion-dev
- Flex
- FontForge (20060125 or newer)
- GNU Bison
- GNU Compiler Collection (3.4 or newer, 4.x recommended)
- GNU gettext (0.17 or newer)
- GNU Make (3.78 or newer)
- MetaFont (mf-nowin, mf, mfw or mfont binaries), usually packaged with TeX.
- MetaPost (mpost binary), usually packaged with TeX.
- Perl
- Texinfo (4.11 or newer)
- Type 1 utilities (1.33 or newer recommended)
[ << Requirements ] | [Top][Contents][Index][ ? ] | [ Getting the source code >> ] | ||
[ < Requirements for compiling LilyPond ] | [ Up : Requirements ] | [ Getting the source code > ] |
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:
- Everything listed in Requirements for compiling LilyPond
- ImageMagick
- Netpbm
- rsync
- Texi2HTML (1.82)
- International fonts
Red Hat Fedora:
fonts-arabic fonts-hebrew fonts-ja fonts-xorg-truetype taipeifonts ttfonts-ja ttfonts-zh_CN
Debian GNU/Linux:
emacs-intl-fonts ttf-kochi-gothic ttf-kochi-mincho xfonts-bolkhov-75dpi xfonts-cronyx-75dpi xfonts-cronyx-100dpi xfonts-intl-.*
[ << Requirements ] | [Top][Contents][Index][ ? ] | [ Configuring make >> ] | ||
[ < Requirements for building documentation ] | [ Up : Top ] | [ Configuring make > ] |
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.
[ << Getting the source code ] | [Top][Contents][Index][ ? ] | [ Compiling LilyPond >> ] | ||
[ < Getting the source code ] | [ Up : Top ] | [ Running ./autogen.sh > ] |
4. Configuring make
4.1 Running ./autogen.sh | ||
4.2 Running ./configure |
[ << Configuring make ] | [Top][Contents][Index][ ? ] | [ Compiling LilyPond >> ] | ||
[ < Configuring make ] | [ Up : Configuring make ] | [ Running ./configure > ] |
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
This will:
- generate a number of files and directories to aid configuration, such as ‘configure’, ‘README.txt’, etc.
- automatically run the
./configure
command.
[ << Configuring make ] | [Top][Contents][Index][ ? ] | [ Compiling LilyPond >> ] | ||
[ < Running ./autogen.sh ] | [ Up : Configuring make ] | [ Configuration options > ] |
4.2 Running ./configure
Configuration options | ||
Checking build dependencies | ||
Configuring target directories | ||
Making an out-of-tree build |
[ << Configuring make ] | [Top][Contents][Index][ ? ] | [ Compiling LilyPond >> ] | ||
[ < Running ./configure ] | [ Up : Running ./configure ] | [ Checking build dependencies > ] |
Configuration options
The ./configure
command (generated by
./autogen.sh
) provides many options for configuring
make
. To see them all, run:
./configure --help
[ << Configuring make ] | [Top][Contents][Index][ ? ] | [ Compiling LilyPond >> ] | ||
[ < Configuration options ] | [ Up : Running ./configure ] | [ Configuring target directories > ] |
Checking build dependencies
When ./configure
is run without any arguments, it will
check to make sure your system has everything required for
compilation. This is done automatically when
./autogen.sh
is run. 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.
[ << Configuring make ] | [Top][Contents][Index][ ? ] | [ Compiling LilyPond >> ] | ||
[ < Checking build dependencies ] | [ Up : Running ./configure ] | [ Making an out-of-tree build > ] |
Configuring target directories
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.
[ << Configuring make ] | [Top][Contents][Index][ ? ] | [ Compiling LilyPond >> ] | ||
[ < Configuring target directories ] | [ Up : Running ./configure ] | [ Compiling LilyPond > ] |
Making an out-of-tree build
It is possible to compile LilyPond in a build tree different from
the source tree, using the ‘--srcdir’ option of
configure
. Note that in some cases you may need to
remove the output of a previous configure
command by
running make distclean
in the main source directory
before configuring the out-of-tree build:
make distclean mkdir lily-build && cd lily-build sourcedir/configure --srcdir=sourcedir
[ << Configuring make ] | [Top][Contents][Index][ ? ] | [ Post-compilation options >> ] | ||
[ < Making an out-of-tree build ] | [ Up : Top ] | [ Using make > ] |
5. Compiling LilyPond
5.1 Using make | ||
5.2 Saving time with the ‘-j’ option | ||
5.3 Compiling for multiple platforms | ||
5.4 Useful make variables |
[ << Compiling LilyPond ] | [Top][Contents][Index][ ? ] | [ Post-compilation options >> ] | ||
[ < Compiling LilyPond ] | [ Up : Compiling LilyPond ] | [ Saving time with the -j option > ] |
5.1 Using make
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.
[ << Compiling LilyPond ] | [Top][Contents][Index][ ? ] | [ Post-compilation options >> ] | ||
[ < Using make ] | [ Up : Compiling LilyPond ] | [ Compiling for multiple platforms > ] |
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.
[ << Compiling LilyPond ] | [Top][Contents][Index][ ? ] | [ Post-compilation options >> ] | ||
[ < Saving time with the -j option ] | [ Up : Compiling LilyPond ] | [ Useful make variables > ] |
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
[ << Compiling LilyPond ] | [Top][Contents][Index][ ? ] | [ Post-compilation options >> ] | ||
[ < Compiling for multiple platforms ] | [ Up : Compiling LilyPond ] | [ Post-compilation options > ] |
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.
[ << Compiling LilyPond ] | [Top][Contents][Index][ ? ] | [ Problems >> ] | ||
[ < Useful make variables ] | [ Up : Top ] | [ Installing LilyPond from a local build > ] |
6. Post-compilation options
6.1 Installing LilyPond from a local build | ||
6.2 Generating documentation | ||
6.3 Testing LilyPond binary |
[ << Post-compilation options ] | [Top][Contents][Index][ ? ] | [ Problems >> ] | ||
[ < Post-compilation options ] | [ Up : Post-compilation options ] | [ Generating documentation > ] |
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.
[ << Post-compilation options ] | [Top][Contents][Index][ ? ] | [ Problems >> ] | ||
[ < Installing LilyPond from a local build ] | [ Up : Post-compilation options ] | [ Documentation editor's edit/compile cycle > ] |
6.2 Generating documentation
Documentation editor’s edit/compile cycle | ||
Building documentation | ||
Saving time with CPU_COUNT | ||
AJAX search | ||
Installing documentation | ||
Building documentation without compiling |
[ << Post-compilation options ] | [Top][Contents][Index][ ? ] | [ Problems >> ] | ||
[ < Generating documentation ] | [ Up : Generating documentation ] | [ Building documentation > ] |
Documentation editor’s edit/compile cycle
-
Initial documentation build:
make [-jX] make [-jX CPU_COUNT=X] doc ## can take an hour or more
-
Edit/compile cycle:
## edit source files, then... make [-jX] ## needed if editing outside ## Documentation/, but useful anyway ## for finding Texinfo errors. touch Documentation/*te?? ## bug workaround make [-jX CPU_COUNT=X] doc ## usually faster than initial build.
-
Reset:
make doc-clean ## use only as a last resort.
[ << Post-compilation options ] | [Top][Contents][Index][ ? ] | [ Problems >> ] | ||
[ < Documentation editor's edit/compile cycle ] | [ Up : Generating documentation ] | [ Saving time with CPU_COUNT > ] |
Building documentation
After a successful compile (using make
), the
documentation can be built by issuing:
make doc
The first time you run make doc
, the process can
easily take an hour or more. After that, make doc
only makes changes to the pre-built 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.
Compilation of documentation in Info format with images can be done separately by issuing:
make info
Known issues and warnings
If source files have changed since the last documentation build,
output files that need to be rebuilt are normally rebuilt, even if
you do not run make doc-clean
first. However, build
dependencies in the documentation are so complex that some
newly-edited files may not be rebuilt as they should be; a
workaround is to touch
the top source file for any
manual you’ve edited. For example, if you make changes to a file
in ‘notation/’, do:
touch Documentation/notation.tely
The top sources possibly affected by this are:
Documentation/extend.texi Documentation/changes.tely Documentation/contributor.texi Documentation/essay.tely Documentation/extending.tely Documentation/learning.tely Documentation/notation.tely Documentation/snippets.tely Documentation/usage.tely Documentation/web.texi
You can touch
all of them at once with:
touch Documentation/*te??
However, this will rebuild all of the manuals
indiscriminately—it is more efficient to touch
only
the affected files.
[ << Post-compilation options ] | [Top][Contents][Index][ ? ] | [ Problems >> ] | ||
[ < Building documentation ] | [ Up : Generating documentation ] | [ AJAX search > ] |
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.
[ << Post-compilation options ] | [Top][Contents][Index][ ? ] | [ Problems >> ] | ||
[ < Saving time with CPU_COUNT ] | [ Up : Generating documentation ] | [ Installing 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.
[ << Post-compilation options ] | [Top][Contents][Index][ ? ] | [ Problems >> ] | ||
[ < AJAX search ] | [ Up : Generating documentation ] | [ Building documentation without compiling > ] |
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.
[ << Post-compilation options ] | [Top][Contents][Index][ ? ] | [ Problems >> ] | ||
[ < Installing documentation ] | [ Up : Generating documentation ] | [ Testing LilyPond binary > ] |
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 "$@"
[ << Post-compilation options ] | [Top][Contents][Index][ ? ] | [ Problems >> ] | ||
[ < Building documentation without compiling ] | [ Up : Post-compilation options ] | [ Problems > ] |
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.
[ << Post-compilation options ] | [Top][Contents][Index][ ? ] | [ Concurrent stable and development versions >> ] | ||
[ < Testing LilyPond binary ] | [ Up : Top ] | [ > ] |
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.
[ << Problems ] | [Top][Contents][Index][ ? ] | [ Concurrent stable and development versions >> ] | ||
[ < 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
[ << Problems ] | [Top][Contents][Index][ ? ] | [ Concurrent stable and development versions >> ] | ||
[ < ] | [ 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
[ << Problems ] | [Top][Contents][Index][ ? ] | [ Concurrent stable and development versions >> ] | ||
[ < ] | [ 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
[ << Problems ] | [Top][Contents][Index][ ? ] | [ Concurrent stable and development versions >> ] | ||
[ < ] | [ 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>
[ << Problems ] | [Top][Contents][Index][ ? ] | [ Concurrent stable and development versions >> ] | ||
[ < ] | [ 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
[ << Problems ] | [Top][Contents][Index][ ? ] | [ Concurrent stable and development versions >> ] | ||
[ < ] | [ Up : Problems ] | [ Concurrent stable and development versions > ] |
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.
[ << Problems ] | [Top][Contents][Index][ ? ] | [ Using a Virtual Machine to Compile LilyPond >> ] | ||
[ < ] | [ Up : Top ] | [ Using a Virtual Machine to Compile LilyPond > ] |
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
[ << Concurrent stable and development versions ] | [Top][Contents][Index][ ? ] | [ Build system >> ] | ||
[ < Concurrent stable and development versions ] | [ Up : Top ] | [ Build system > ] |
9. Using a Virtual Machine to Compile LilyPond
TODO: rewrite for lily-git.tcl !!! do before GOP! -gp
Since it is not possible to compile Lilypond on Windows, some
developers may find it useful to install a GNU/Linux virtual
machine. A disk image with a special remix of Ubuntu
has been created for this purpose. It has all of the Lilypond
build dependencies in place, so that once installed, it is
ready to compile both Lilypond and the Documentation.
The lilybuntu
remix is available for download here:
http://files.lilynet.net/lilybuntu.iso
We do not necessarily recommend any one virtualization tool,
however the lilybuntu
remix is known to work well on
Sun VirtualBox,
which is a free download. Consult your virtualization software’s
documentation for instructions on setting up the software and
for general instructions on installing a virtual machine.
Steps to setting up lilybuntu
in a virtual machine:
- Download the
lilybuntu
disk image. - Install
lilybuntu
. You will use the.iso
file as the boot disk. It should not be necessary to burn it to a DVD, but consult the documentation for your virtualization software for specific instructions. If possible, use at least the recommended amount of RAM for the virtual machine (384 MB on VirtualBox), and use a dynamically expanding virtual hard drive. A virtual hard drive with 6 GB will be enough to compile LilyPond, but if you intend to build the docs and run the regression tests the virtual hard drive should be at least 10 GB. The Ubuntu installation should be straightforward, although in the partitioning stage do not be afraid to select “use entire disk,” since this is only your virtual disk and not your machine’s actual hard drive. - After installation is complete, restart the virtual
machine. If you are using VirtualBox, you may wish
to install the “Guest Additions”, which while not essential for
compiling
Lilypond
will allow you to use the virtual machine in full screen, Seamless mode (also known as Unity mode on other virtualization platforms) and allow you to share clipboards between the physical and virtual machine. From theDevices
menu selectInstall Guest Additions...
, theVBOXADDITIONS
CDROM device will appear on the desktop. Open a terminal session. (Applications > Accessories > Terminal
) andcd
to the top level of the CDROM. Run theautorun.sh
script as superuser (sudo ./autorun.sh
), a console window will open while the “Guest Additions” are being installed. Once the script has been finished, reboot your Virtual Machine to complete the installation of the “Guest Additions”. - Open a terminal session.
(
Applications > Accessories > Terminal
) - Open Firefox (there’s an icon for it on the panel at the top of the screen) and go to the online Lilypond Contributor’s Guide.
- To retrieve the Lilypond source code from
git
, copy-and-paste each command from the CG “Main source code” section into the terminal. (paste into the terminal with keystrokeCTRL+SHIFT+V
) - Prepare to build Lilypond by running the configuration script.
Type
./autogen.sh
When it is finished you should be presented with the three most common
make
options:Type: make all to build LilyPond make install to install LilyPond make help to see all possible targets Edit local.make for local Makefile overrides.
- First type
make all
to build Lilypond. This will take a while. - When Lilypond is finished building, build the documentation
by typing
make doc
Depending on your system specs it could take from 30-60 minutes to finish.
At this point everything has been compiled.
You may install Lilypond using make install
, or you may wish
to set up your system with concurrent stable and development
versions as described in the previous section.
[ << Using a Virtual Machine to Compile LilyPond ] | [Top][Contents][Index][ ? ] | [ >> ] | ||
[ < Using a Virtual Machine to Compile LilyPond ] | [ Up : Top ] | [ > ] |
10. 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 macors
-
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) - not (?) used in the main docs?
- 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.
[Top][Contents][Index][ ? ] |
Table of Contents
[Top][Contents][Index][ ? ] |
About This Document
This document was generated by Graham Percival on July 6, 2010 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:
- 1. Section One
- 1.1 Subsection One-One
- ...
- 1.2 Subsection One-Two
- 1.2.1 Subsubsection One-Two-One
- 1.2.2 Subsubsection One-Two-Two
- 1.2.3 Subsubsection One-Two-Three <== Current Position
- 1.2.4 Subsubsection One-Two-Four
- 1.3 Subsection One-Three
- ...
- 1.4 Subsection One-Four
- 1.1 Subsection One-One