1 @c -*- coding: utf-8; mode: texinfo; -*-
4 @c DO NOT TRANSLATE THIS FILE
6 @c include any node/sections from the higher-level *texi file.
7 @c @n ode Compiling from source
8 @c @s ection Compiling from source
11 * Overview of compiling::
13 * Getting the source code::
15 * Compiling LilyPond::
16 * Post-compilation options::
18 * Concurrent stable and development versions::
23 @node Overview of compiling
24 @section Overview of compiling
26 Compiling LilyPond from source is an involved process, and is only
27 recommended for developers and packagers. Typical program users
28 are instead encouraged to obtain the program from a package
29 manager (on Unix) or by downloading a precompiled binary
30 configured for a specific operating system. Pre-compiled binaries
31 are available on the @rweb{Download} page.
33 Compiling LilyPond from source is necessary if you want to build,
34 install, or test your own version of the program.
36 A successful compile can also be used to generate and install the
37 documentation, incorporating any changes you may have made.
38 However, a successful compile is not a requirement for generating
39 the documentation. The documentation can be built using a Git
40 repository in conjunction with a locally installed copy of the
41 program. For more information, see @ref{Building documentation
44 Attempts to compile LilyPond natively on Windows have been
45 unsuccessful, though a workaround is available (see
54 * Requirements for running LilyPond::
55 * Requirements for compiling LilyPond::
56 * Requirements for building documentation::
60 @node Requirements for running LilyPond
61 @subsection Requirements for running LilyPond
63 Running LilyPond requires proper installation of the following
67 @item @uref{http://www.dejavu-fonts.org/, DejaVu fonts} (normally
70 @item @uref{http://www.fontconfig.org/, FontConfig} (2.4.0 or newer)
72 @item @uref{http://www.freetype.org/, Freetype} (2.1.10 or newer)
74 @item @uref{http://www.ghostscript.com, Ghostscript} (8.60 or
77 @item @uref{http://www.gnu.org/software/guile/guile.html, Guile}
80 @item @uref{http://www.pango.org/, Pango} (1.12 or newer)
82 @item @uref{http://www.python.org, Python} (2.4 or newer)
85 International fonts are required to create music with
86 international text or lyrics.
89 @node Requirements for compiling LilyPond
90 @subsection Requirements for compiling LilyPond
92 Below is a full list of packages needed to build LilyPond.
93 However, for most common distributions there is an easy way of
94 installing most all build dependencies in one go:
96 @multitable @columnfractions .5 .5
97 @headitem Distribution @tab Command
99 @tab @code{sudo apt-get build-dep lilypond}
102 @tab @code{sudo yum-builddep lilypond}
105 @c sorry for the idiosyncratic command, I really asked and argued
106 @c for "zypper build-dep" :-(
107 @tab @code{sudo zypper --build-deps-only source-install lilypond}
111 @item Everything listed in @ref{Requirements for running
114 @item Development packages for the above items (which should
115 include header files and libraries).
119 @c ghostscript-devel-[version] isn't needed
121 guile-devel-@var{version}
122 fontconfig-devel-@var{version}
123 freetype-devel-@var{version}
124 pango-devel-@var{version}
125 python-devel-@var{version}
130 @c libgs-dev isn't needed
132 guile-@var{version}-dev
136 python@var{version}-dev
139 @item @uref{http://flex.sourceforge.net/, Flex}
141 @item @uref{http://fontforge.sf.net/, FontForge} (20060125 or
142 newer; 20100501 or newer is recommended; must be compiled
143 with @option{--enable-double}. Failure to do so can lead to
144 poor intersection calculations and poorly-rendered glyphs.)
146 @item @uref{http://www.gnu.org/software/bison/, GNU Bison}
148 @item @uref{http://gcc.gnu.org/, GNU Compiler Collection} (3.4 or
149 newer, 4.@var{x} recommended)
151 @item @uref{http://www.gnu.org/software/gettext/gettext.html, GNU
152 gettext} (0.17 or newer)
154 @item @uref{http://www.gnu.org/software/make/, GNU Make} (3.78 or
157 @item @uref{http://metafont.tutorial.free.fr/, MetaFont}
158 (mf-nowin, mf, mfw or mfont binaries), usually packaged with
159 @uref{http://www.latex-project.org/ftp.html, @TeX{}}.
161 @item @uref{http://cm.bell-labs.com/who/hobby/MetaPost.html,
162 MetaPost} (mpost binary), usually packaged with
163 @uref{http://www.latex-project.org/ftp.html, @TeX{}}.
165 @item @uref{http://www.perl.org/, Perl}
167 @item @uref{http://www.gnu.org/software/texinfo/, Texinfo} (4.11
170 @item @uref{http://www.lcdf.org/~eddietwo/type/#t1utils, Type 1
171 utilities} (1.33 or newer recommended)
175 @node Requirements for building documentation
176 @subsection Requirements for building documentation
178 You can view the documentation online at
179 @uref{http://www.lilypond.org/doc/}, but you can also build it
180 locally. This process requires some additional tools and
184 @item Everything listed in @ref{Requirements for compiling
187 @item @uref{http://www.imagemagick.org/, ImageMagick}
189 @item @uref{http://netpbm.sourceforge.net/, Netpbm}
191 @item @uref{http://gzip.org/, gzip}
193 @item @uref{http://rsync.samba.org/, rsync}
195 @item @uref{http://www.nongnu.org/texi2html/, Texi2HTML} (1.82)
197 @item International fonts
225 @node Getting the source code
226 @section Getting the source code
229 @subheading Downloading the Git repository
231 In general, developers compile LilyPond from within a local Git
232 repository. Setting up a local Git repository is explained in
233 @rcontrib{Starting with Git}.
236 @subheading Downloading a source tarball
238 Packagers are encouraged to use source tarballs for compiling.
240 The tarball for the latest stable release is available on the
245 @uref{http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=snapshot, source code snapshot}
246 is also available as a tarball from the GNU Savannah Git server.
249 All tagged releases (including legacy stable
250 versions and the most recent development release) are available
254 @uref{http://download.linuxaudio.org/lilypond/source/}
257 Download the tarball to your @file{~/src/} directory, or some
258 other appropriate place.
260 @warning{Be careful where you unpack the tarball! Any
261 subdirectories of the current folder named @file{lilypond/} or
262 @file{lilypond-@var{x.y.z}/} (where @var{x.y.z} is the release
263 number) will be overwritten if there is a name clash with the
266 Unpack the tarball with this command:
269 tar -xzf lilypond-@var{x.y.z}.tar.gz
272 This creates a subdirectory within the current directory called
273 @file{lilypond-@var{x.y.z}/}. Once unpacked, the source files
274 occupy about 40 MB of disk space.
276 Windows users wanting to look at the source code may have to
277 download and install the free-software
278 @uref{http://www.7-zip.org, 7zip archiver} to extract the tarball.
281 @node Configuring make
282 @section Configuring @command{make}
286 * Running ./autogen.sh::
287 * Running ../configure::
291 @node Running ./autogen.sh
292 @subsection Running @command{./autogen.sh}
294 After you unpack the tarball (or download the Git repository), the
295 contents of your top source directory should be similar to the
296 current source tree listed at
297 @uref{http://git.sv.gnu.org/gitweb/?p=lilypond.git;a=tree}.
299 Next, you need to create the generated files; enter the following
300 command from your top source directory:
303 ./autogen.sh --noconfigure
306 This will generate a number of files and directories to aid
307 configuration, such as @file{configure}, @file{README.txt}, etc.
309 Next, create the build directory with:
316 We heavily recommend building lilypond inside a separate directory
320 @node Running ../configure
321 @subsection Running @command{../configure}
325 * Configuration options::
326 * Checking build dependencies::
327 * Configuring target directories::
331 @node Configuration options
332 @unnumberedsubsubsec Configuration options
334 @warning{make sure that you are in the @file{build/} subdirectory
335 of your source tree.}
337 The @command{../configure} command (generated by
338 @command{./autogen.sh}) provides many options for configuring
339 @command{make}. To see them all, run:
346 @node Checking build dependencies
347 @unnumberedsubsubsec Checking build dependencies
349 @warning{make sure that you are in the @file{build/} subdirectory
350 of your source tree.}
352 When @command{../configure} is run without any arguments, it will
353 check to make sure your system has everything required for
360 If any build dependency is missing, @command{../configure} will
364 ERROR: Please install required programs: @var{foo}
367 The following message is issued if you are missing programs that
368 are only needed for building the documentation:
371 WARNING: Please consider installing optional programs: @var{bar}
374 If you intend to build the documentation locally, you will need to
375 install or update these programs accordingly.
377 @warning{@command{../configure} may fail to issue warnings for
378 certain documentation build requirements that are not met. If you
379 experience problems when building the documentation, you may need
380 to do a manual check of @ref{Requirements for building
384 @node Configuring target directories
385 @unnumberedsubsubsec Configuring target directories
387 @warning{make sure that you are in the @file{build/} subdirectory
388 of your source tree.}
390 If you intend to use your local build to install a local copy of
391 the program, you will probably want to configure the installation
392 directory. Here are the relevant lines taken from the output of
393 @command{../configure@tie{}--help}:
396 By default, `@command{make@tie{}install}' will install all the
397 files in @file{/usr/local/bin}, @file{/usr/local/lib} etc. You
398 can specify an installation prefix other than @file{/usr/local}
399 using `@option{--prefix}', for instance `@option{--prefix=$HOME}'.
402 A typical installation prefix is @file{$HOME/usr}:
405 ../configure --prefix=$HOME/usr
408 Note that if you plan to install a local build on a system where
409 you do not have root privileges, you will need to do something
410 like this anyway---@command{make@tie{}install} will only succeed
411 if the installation prefix points to a directory where you have
412 write permission (such as your home directory). The installation
413 directory will be automatically created if necessary.
415 The location of the @command{lilypond} command installed by this
416 process will be @file{@var{prefix}/bin/lilypond}; you may want to
417 add @file{@var{prefix}/bin/} to your @code{$PATH} if it is not
420 It is also possible to specify separate installation directories
421 for different types of program files. See the full output of
422 @command{../configure@tie{}--help} for more information.
424 If you encounter any problems, please see @ref{Problems}.
427 @node Compiling LilyPond
428 @section Compiling LilyPond
433 * Saving time with the -j option::
434 * Compiling for multiple platforms::
435 * Useful make variables::
440 @subsection Using @command{make}
442 @warning{make sure that you are in the @file{build/} subdirectory
443 of your source tree.}
445 LilyPond is compiled with the @command{make} command. Assuming
446 @command{make} is configured properly, you can simply run:
452 @samp{make} is short for @samp{make all}. To view a list of @command{make}
459 TODO: Describe what @command{make} actually does.
462 @node Saving time with the -j option
463 @subsection Saving time with the @option{-j} option
465 If your system has multiple CPUs, you can speed up compilation by
466 adding @samp{-j@var{X}} to the @command{make} command, where
467 @samp{@var{X}} is one more than the number of cores you have. For
468 example, a typical Core2Duo machine would use:
474 If you get errors using the @option{-j} option, and @samp{make}
475 succeeds without it, try lowering the @code{@var{X}} value.
477 Because multiple jobs run in parallel when @option{-j} is used, it can
478 be difficult to determine the source of an error when one occurs. In
479 that case, running @samp{make} without the @option{-j} is advised.
481 @node Compiling for multiple platforms
482 @subsection Compiling for multiple platforms
484 If you want to build multiple versions of LilyPond with different
485 configuration settings, you can use the
486 @option{--enable-config=@var{conf}} option of @command{configure}.
487 You should use @code{make@tie{}conf=@var{conf}} to generate the
488 output in @file{out-@var{conf}}. For example, suppose you want to
489 build with and without profiling, then use the following for the
493 ./configure --prefix=$HOME/usr/ --enable-checking
497 and for the profiling version, specify a different configuration
500 ./configure --prefix=$HOME/usr/ --enable-profiling \
501 --enable-config=prof --disable-checking
505 If you wish to install a copy of the build with profiling, don't
506 forget to use @code{conf=@var{CONF}} when issuing
507 @command{make@tie{}install}:
510 make conf=prof install
515 @ref{Installing LilyPond from a local build}
518 @node Useful make variables
519 @subsection Useful @command{make} variables
521 If a less verbose build output if desired, the variable
522 @code{QUIET_BUILD} may be set to @code{1} on @command{make}
523 command line, or in @file{local.make} at top of the build tree.
526 @node Post-compilation options
527 @section Post-compilation options
531 * Installing LilyPond from a local build::
532 * Generating documentation::
533 * Testing LilyPond binary::
537 @node Installing LilyPond from a local build
538 @subsection Installing LilyPond from a local build
540 If you configured @command{make} to install your local build in a
541 directory where you normally have write permission (such as your
542 home directory), and you have compiled LilyPond by running
543 @command{make}, you can install the program in your target
544 directory by running:
550 If instead, your installation directory is not one that you can
551 normally write to (such as the default @file{/usr/local/}, which
552 typically is only writeable by the superuser), you will need to
553 temporarily become the superuser when running
554 @command{make@tie{}install}:
567 If you don't have superuser privileges, then you need to configure
568 the installation directory to one that you can write to, and then
569 re-install. See @ref{Configuring target directories}.
572 @node Generating documentation
573 @subsection Generating documentation
577 * Documentation editor's edit/compile cycle::
578 * Building documentation::
579 * Building a single document::
580 * Saving time with CPU_COUNT::
582 * Installing documentation::
583 * Building documentation without compiling::
587 @node Documentation editor's edit/compile cycle
588 @unnumberedsubsubsec Documentation editor's edit/compile cycle
592 Initial documentation build:
596 make [-j@var{X} CPU_COUNT=@var{X}] doc @emph{## can take an hour or more}
603 @emph{## edit source files, then...}
605 make [-j@var{X}] @emph{## needed if editing outside}
606 @emph{## Documentation/, but useful anyway}
607 @emph{## for finding Texinfo errors.}
608 make [-j@var{X} CPU_COUNT=@var{X}] doc @emph{## usually faster than initial build.}
614 In some cases, it is possible to clean the compiled documentation
615 with @samp{make@tie{}doc-clean}, but this method is not guaranteed
616 to fix everything. Instead, we recommend that you delete your
617 @file{build/} directory, and begin compiling from scratch. Since
618 the documentation compile takes much longer than the
619 non-documentation compile, this does not increase the overall time
624 @node Building documentation
625 @unnumberedsubsubsec Building documentation
627 After a successful compile (using @command{make}), the
628 documentation can be built by issuing:
634 The first time you run @command{make@tie{}doc}, the process can
635 easily take an hour or more. After that, @command{make@tie{}doc}
636 only makes changes to the pre-built documentation where needed,
637 so it may only take a minute or two to test changes if the
638 documentation is already built.
640 If @command{make@tie{}doc} succeeds, the HTML documentation tree
641 is available in @file{out-www/offline-root/}, and can be browsed
642 locally. Various portions of the documentation can be found by
643 looking in @file{out/} and @file{out-www} subdirectories in other
644 places in the source tree, but these are only @emph{portions} of
645 the docs. Please do not complain about anything which is broken
646 in those places; the only complete set of documentation is in
647 @file{out-www/offline-root/} from the top of the source tree.
649 @code{make doc} compiles the documents for all languages. To save
650 some compile time, the English language documents can be compiled
657 @noindent Similarly, it is possible to compile a subset of the
658 translated documentation by specifying their language codes on the
659 command line. For example, the French and German translations are
663 make LANGS='de fr' doc
666 @noindent Note that this will also compile the English version.
668 Compilation of documentation in Info format with images can be
669 done separately by issuing:
677 If source files have changed since the last documentation build,
678 output files that need to be rebuilt are normally rebuilt, even if
679 you do not run @code{make@tie{}doc-clean} first. However, build
680 dependencies in the documentation are so complex that some
681 newly-edited files may not be rebuilt as they should be; a
682 workaround is to @command{touch} the top source file for any
683 manual you've edited. For example, if you make changes to a file
684 in @file{notation/}, do:
687 touch Documentation/notation.tely
691 The top sources possibly affected by this are:
694 Documentation/extend.texi
695 Documentation/changes.tely
696 Documentation/contributor.texi
697 Documentation/essay.tely
698 Documentation/extending.tely
699 Documentation/learning.tely
700 Documentation/notation.tely
701 Documentation/snippets.tely
702 Documentation/usage.tely
703 Documentation/web.texi
707 You can @command{touch} all of them at once with:
710 touch Documentation/*te??
714 However, this will rebuild all of the manuals
715 indiscriminately---it is more efficient to @command{touch} only
719 Another typical issue when switching branches between master and
720 lilypond/translation is the appearance/disappearance of translated
721 versions of some manuals. If you see such a warning from make:
724 No rule to make target `X', needed by `Y'
728 Your best bet is to delete the file Y.dep and to try again.
730 @node Building a single document
731 @unnumberedsubsubsec Building a single document
732 It's possible to build a single document. For example, to rebuild
733 only @file{contributor.pdf}, do the following:
738 touch ../../Documentation/contributor.texi
739 make out=www out-www/contributor.pdf
742 If you are only working on a single document, test-building it in
743 this way can give substantial time savings - recreating
744 @file{contributor.pdf}, for example, takes a matter of seconds.
746 @node Saving time with CPU_COUNT
747 @unnumberedsubsubsec Saving time with @code{CPU_COUNT}
749 The most time consuming task for building the documentation is
750 running LilyPond to build images of music, and there cannot be
751 several simultaneously running @command{lilypond-book} instances,
752 so the @option{-j} @command{make} option does not significantly
753 speed up the build process. To help speed it up, the makefile
754 variable @option{CPU_COUNT} may be set in @file{local.make} or on
755 the command line to the number of @code{.ly} files that LilyPond
756 should process simultaneously, e.g. on a bi-processor or dual core
760 make -j3 CPU_COUNT=3 doc
764 The recommended value of @option{CPU_COUNT} is one plus the number
765 of cores or processors, but it is advisable to set it to a smaller
766 value unless your system has enough RAM to run that many
767 simultaneous LilyPond instances. Also, values for the @option{-j}
768 option that pose problems with @samp{make} are less likely to pose
769 problems with @samp{make doc} (this applies to both @option{-j}
770 and @option{CPU_COUNT}). For example, with a quad-core processor,
771 it is possible for @samp{make -j5 CPU_COUNT=5 doc} to work
772 consistently even if @samp{make -j5} rarely succeeds.
776 @unnumberedsubsubsec AJAX search
778 To build the documentation with interactive searching, use:
781 make doc AJAX_SEARCH=1
784 This requires PHP, and you must view the docs via a http
785 connection (you cannot view them on your local filesystem).
787 @warning{Due to potential security or load issues, this option is
788 not enabled in the official documentation builds. Enable at your
792 @node Installing documentation
793 @unnumberedsubsubsec Installing documentation
795 The HTML, PDF and if available Info files can be installed into
796 the standard documentation path by issuing
803 This also installs Info documentation with images if the
804 installation prefix is properly set; otherwise, instructions to
805 complete proper installation of Info documentation are printed on
808 To install the Info documentation separately, run:
815 Note that to get the images in Info documentation, @code{install-doc}
816 target creates symbolic links to HTML and PDF installed documentation
817 tree in @file{@var{prefix}/share/info}, in order to save disk space,
818 whereas @code{install-info} copies images in
819 @file{@var{prefix}/share/info} subdirectories.
821 It is possible to build a documentation tree in
822 @file{out-www/online-root/}, with special processing, so it can be
823 used on a website with content negotiation for automatic language
824 selection; this can be achieved by issuing
827 make WEB_TARGETS=online doc
831 and both @q{offline} and @q{online} targets can be generated by issuing
834 make WEB_TARGETS="offline online" doc
837 Several targets are available to clean the documentation build and
838 help with maintaining documentation; an overview of these targets is
846 from every directory in the build tree. Most targets for
847 documentation maintenance are available from
848 @file{Documentation/}; for more information, see
849 @rcontrib{Documentation work}.
851 The makefile variable @code{QUIET_BUILD} may be set to @code{1}
852 for a less verbose build output, just like for building the
856 @node Building documentation without compiling
857 @unnumberedsubsubsec Building documentation without compiling
860 The documentation can be built locally without compiling LilyPond
861 binary, if LilyPond is already installed on your system.
863 From a fresh Git checkout, do
866 ./autogen.sh # ignore any warning messages
867 cp GNUmakefile.in GNUmakefile
868 make -C scripts && make -C python
869 nice make LILYPOND_EXTERNAL_BINARY=/path/to/bin/lilypond doc
872 Please note that this may break sometimes -- for example, if a new
873 feature is added with a test file in input/regression, even the latest
874 development release of LilyPond will fail to build the docs.
876 You may build the manual without building all the @file{input/*} stuff
877 (i.e. mostly regression tests): change directory, for example to
878 @file{Documentation/}, issue @code{make doc}, which will build
879 documentation in a subdirectory @file{out-www} from the source files in
880 current directory. In this case, if you also want to browse the
881 documentation in its post-processed form, change back to top directory
885 make out=www WWW-post
890 You may also need to create a script for @command{pngtopnm} and
891 @code{pnmtopng}. On GNU/Linux, I use this:
894 export LD_LIBRARY_PATH=/usr/lib
895 exec /usr/bin/pngtopnm "$@"
898 On MacOS X with fink, I use this:
901 export DYLD_LIBRARY_PATH=/sw/lib
902 exec /sw/bin/pngtopnm "$@"
905 On MacOS X with macports, you should use this:
908 export DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib
909 exec /opt/local/bin/pngtopnm "$@"
913 @node Testing LilyPond binary
914 @subsection Testing LilyPond binary
917 LilyPond comes with an extensive suite that exercises the entire
918 program. This suite can be used to test that the binary has
919 been built correctly.
921 The test suite can be executed with:
927 If the test suite completes successfully, the LilyPond binary
930 More information on the regression test suite is found at
931 @rcontrib{Regression tests}.
936 For help and questions use @email{lilypond-user@@gnu.org}. Send
937 bug reports to @email{bug-lilypond@@gnu.org}.
939 Bugs that are not fault of LilyPond are documented here.
941 @unnumberedsubsubsec Bison 1.875
943 There is a bug in bison-1.875: compilation fails with "parse error
944 before `goto'" in line 4922 due to a bug in bison. To fix, please
945 recompile bison 1.875 with the following fix
948 $ cd lily; make out/parser.cc
949 $ vi +4919 out/parser.cc
950 # append a semicolon to the line containing "__attribute__ ((__unused__))
956 @unnumberedsubsubsec Compiling on MacOS@tie{}X
958 Here are special instructions for compiling under MacOS@tie{}X.
959 These instructions assume that dependencies are installed using
960 @uref{http://www.macports.org/, MacPorts.} The instructions have
961 been tested using OS X 10.5 (Leopard).
963 First, install the relevant dependencies using MacPorts.
965 Next, add the following to your relevant shell initialization
966 files. This is @code{~/.profile} by default. You should create
967 this file if it does not exist.
970 export PATH=/opt/local/bin:/opt/local/sbin:$PATH
971 export DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib:$DYLD_FALLBACK_LIBRARY_PATH
974 Now you must edit the generated @file{config.make} file. Change
977 FLEXLEXER_FILE = /usr/include/FlexLexer.h
984 FLEXLEXER_FILE = /opt/local/include/FlexLexer.h
987 At this point, you should verify that you have the appropriate
988 fonts installed with your ghostscript installation. Check @code{ls
989 /opt/local/share/ghostscript/fonts} for: 'c0590*' files (.pfb,
990 .pfb and .afm). If you don't have them, run the following
991 commands to grab them from the ghostscript SVN server and install
992 them in the appropriate location:
995 svn export http://svn.ghostscript.com/ghostscript/tags/urw-fonts-1.0.7pre44/
996 sudo mv urw-fonts-1.0.7pre44/* /opt/local/share/ghostscript/fonts/
997 rm -rf urw-fonts-1.07pre44
1000 Now run the @code{./configure} script. To avoid complications with
1001 automatic font detection, add
1004 --with-ncsb-dir=/opt/local/share/ghostscript/fonts
1008 @unnumberedsubsubsec Solaris
1010 Solaris7, ./configure
1012 @file{./configure} needs a POSIX compliant shell. On Solaris7,
1013 @file{/bin/sh} is not yet POSIX compliant, but @file{/bin/ksh} or bash
1014 is. Run configure like
1017 CONFIG_SHELL=/bin/ksh ksh -c ./configure
1024 CONFIG_SHELL=/bin/bash bash -c ./configure
1027 @unnumberedsubsubsec FreeBSD
1029 To use system fonts, dejaview must be installed. With the default
1030 port, the fonts are installed in @file{usr/X11R6/lib/X11/fonts/dejavu}.
1032 Open the file @file{$LILYPONDBASE/usr/etc/fonts/local.conf} and add the
1033 following line just after the @code{<fontconfig>} line. (Adjust as necessary
1034 for your hierarchy.)
1037 <dir>/usr/X11R6/lib/X11/fonts</dir>
1041 @unnumberedsubsubsec International fonts
1043 On Mac OS X, all fonts are installed by default. However, finding all
1044 system fonts requires a bit of configuration; see
1045 @uref{http://lists.gnu.org/archive/html/lilypond-user/2007-03/msg00472.html,
1046 this post} on the @code{lilypond-user} mailing list.
1048 On Linux, international fonts are installed by different means on
1049 every distribution. We cannot list the exact commands or packages
1050 that are necessary, as each distribution is different, and the exact
1051 package names within each distribution changes. Here are some
1057 taipeifonts fonts-xorg-truetype ttfonts-ja fonts-arabic \
1058 ttfonts-zh_CN fonts-ja fonts-hebrew
1062 apt-get install emacs-intl-fonts xfonts-intl-.* \
1063 ttf-kochi-gothic ttf-kochi-mincho \
1064 xfonts-bolkhov-75dpi xfonts-cronyx-100dpi xfonts-cronyx-75dpi
1068 @unnumberedsubsubsec Using lilypond python libraries
1070 If you want to use lilypond's python libraries (either running
1071 certain build scripts manually, or using them in other programs),
1072 set @code{PYTHONPATH} to @file{python/out} in your build
1073 directory, or @file{.../usr/lib/lilypond/current/python} in the
1074 installation directory structure.
1079 @node Concurrent stable and development versions
1080 @section Concurrent stable and development versions
1083 It can be useful to have both the stable and the development versions
1084 of Lilypond available at once. One way to do this on GNU/Linux is to
1085 install the stable version using the precompiled binary, and run the
1086 development version from the source tree. After running @command{make
1087 all} from the top directory of the Lilypond source files, there will
1088 be a binary called @code{lilypond} in the @code{out} directory:
1091 <@var{path to}>/lilypond/out/bin/lilypond
1094 This binary can be run without actually doing the @code{make
1095 install} command. The advantage to this is that you can have all
1096 of the latest changes available after pulling from git and running
1097 @code{make all}, without having to uninstall the old version and
1100 So, to use the stable version, install it as usual and use the
1107 To use the development version, create a link to the binary in the
1108 source tree by saving the following line in a file somewhere in your
1112 exec <@var{path to}>/lilypond/out/bin/lilypond "$@@"
1115 Save it as @code{Lilypond} (with a capital L to distinguish it
1116 from the stable @code{lilypond}), and make it executable:
1122 Then you can invoke the development version this way:
1131 - other compilation tricks for developers
1135 @section Build system
1138 We currently use make and stepmake, which is complicated and only
1139 used by us. Hopefully this will change in the future.
1142 @subsubheading Version-specific texinfo macros
1147 made with @command{scripts/build/create-version-itexi.py} and@*
1148 @command{scripts/build/create-weblinks-itexi.py}
1151 used extensively in the @code{WEBSITE_ONLY_BUILD} version of the
1152 website (made with @file{website.make}, used on lilypond.org)
1155 not (?) used in the main docs?
1158 the numbers in VERSION file: MINOR_VERSION should be 1 more than
1159 the last release, VERSION_DEVEL should be the last @strong{online}
1160 release. Yes, VERSION_DEVEL is less than VERSION.