X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=INSTALL.txt;h=b285145bd22e5346c7c4e4c73e1eaa5fe09be8d6;hb=074edde46fd433dbf52c482f3b087e80587db001;hp=594698c1d8e161f3a2f341f5ff30036c45dd70e4;hpb=941dff9d2a67080e0dd8474f1e70f0c72ace6424;p=lilypond.git diff --git a/INSTALL.txt b/INSTALL.txt index 594698c1d8..b285145bd2 100644 --- a/INSTALL.txt +++ b/INSTALL.txt @@ -1,57 +1,61 @@ INSTALL - compiling and installing GNU LilyPond *********************************************** -Table of Contents -***************** -INSTALL - compiling and installing GNU LilyPond - Overview of compiling - Requirements - Requirements for running LilyPond - Requirements for compiling LilyPond - Requirements for building documentation - Getting the source code - Configuring `make' - Running `./autogen.sh' - Running `../configure' +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’ Configuration options Checking build dependencies Configuring target directories - Compiling LilyPond - Using `make' - Saving time with the `-j' option - Compiling for multiple platforms - Useful `make' variables - Post-compilation options - Installing LilyPond from a local build - Generating documentation - Documentation editor's edit/compile cycle + 1.5 Compiling LilyPond + 1.5.1 Using ‘make’ + 1.5.2 Saving time with the ‘-j’ option + 1.5.3 Compiling for multiple platforms + 1.5.4 Useful ‘make’ variables + 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 Building documentation - Saving time with `CPU_COUNT' + Building a single document + Saving time with ‘CPU_COUNT’ AJAX search Installing documentation Building documentation without compiling - Testing LilyPond binary - Problems - Bison 1.875 - Compiling on MacOS X - Solaris - FreeBSD - International fonts - Using lilypond python libraries - Concurrent stable and development versions - Build system - - -Overview of compiling -===================== + 1.6.3 Testing LilyPond binary + 1.7 Problems + Compiling on MacOS X + Solaris + FreeBSD + International fonts + Using lilypond python libraries + 1.8 Concurrent stable and development versions + 1.9 Build system +1 Compilation +************* + +1.1 Overview of compiling +========================= Compiling LilyPond from source is an involved process, and is only recommended for developers and packagers. Typical program users are instead encouraged to obtain the program from a package manager (on Unix) or by downloading a precompiled binary configured for a specific operating system. Pre-compiled binaries are available on the *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. @@ -59,158 +63,437 @@ 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::). -Requirements -============ +1.2 Requirements +================ -Requirements for running LilyPond ---------------------------------- +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/) (normally installed by - default) + • DejaVu fonts (http://www.dejavu-fonts.org/) These are normally + installed by default. - * FontConfig (http://www.fontconfig.org/) (2.4.0 or newer) + • FontConfig (http://www.fontconfig.org/) Use version 2.4.0 or newer. - * Freetype (http://www.freetype.org/) (2.1.10 or newer) + • Freetype (http://www.freetype.org/) Use version 2.1.10 or newer. - * Ghostscript (http://www.ghostscript.com) (8.60 or newer) + • Ghostscript (http://www.ghostscript.com) Use version 8.60 or newer. - * Guile (http://www.gnu.org/software/guile/guile.html) (1.8.2 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. - * Pango (http://www.pango.org/) (1.12 or newer) + • Pango (http://www.pango.org/) User version 1.12 or newer. - * Python (http://www.python.org) (2.4 or newer) + • Python (http://www.python.org) Use version 2.4 or newer. - International fonts are required to create music with international -text or lyrics. + • International fonts. For example: -Requirements for compiling LilyPond ------------------------------------ + Fedora: -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: + 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-.* -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' + These are normally installed by default and are required only to + create music with international text or lyrics. - * Everything listed in *note Requirements for running LilyPond:: +1.2.2 Requirements for compiling LilyPond +----------------------------------------- - * Development packages for the above items (which should include - header files and libraries). +This section contains instructions on how to quickly and easily get all +the software packages required to build LilyPond. - Red Hat Fedora: + 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. - guile-devel-VERSION - fontconfig-devel-VERSION - freetype-devel-VERSION - pango-devel-VERSION - python-devel-VERSION +Fedora +...... - Debian GNU/Linux: +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. - guile-VERSION-dev - libfontconfig1-dev - libfreetype6-dev - libpango1.0-dev - pythonVERSION-dev + • Download and install all the LilyPond build-dependencies + (approximately 700MB); - * Flex (http://flex.sourceforge.net/) + sudo dnf builddep lilypond --nogpgcheck - * 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.) + • Download and install additional ‘build’ tools required for + compiling; - * GNU Bison (http://www.gnu.org/software/bison/) + sudo dnf install autoconf gcc-c++ - * GNU Compiler Collection (http://gcc.gnu.org/) (3.4 or newer, 4.X - recommended) + • Download ‘texi2html 1.82’ directly from: + ; - * GNU gettext (http://www.gnu.org/software/gettext/gettext.html) - (0.17 or newer) + ‘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 Make (http://www.gnu.org/software/make/) (3.78 or newer) + ./configure + make + sudo make install - * MetaFont (http://metafont.tutorial.free.fr/) (mf-nowin, mf, mfw or - mfont binaries), usually packaged with TeX - (http://www.latex-project.org/ftp.html). + 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’. + + texi2html --version + + • 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 dnf install git + + Also see *note (lilypond-notation)Starting with Git::. + + • To use the ‘lily-git.tcl’ GUI; + + sudo dnf install tk + + See *note (lilypond-notation)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-notation)Starting with Git::. + + • To use the ‘lily-git.tcl’ GUI; + + sudo apt-get install tk + + Also see *note (lilypond-notation)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-notation)Starting with Git::. + + • To use the ‘lily-git.tcl’ GUI; + + sudo zypper install tk + + Also see *note (lilypond-notation)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 +...... + +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-notation)Starting with Git::. + + • To use the ‘lily-git.tcl’ GUI; + + sudo apt-get install tk + + Also see *note (lilypond-notation)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. - * MetaPost (http://cm.bell-labs.com/who/hobby/MetaPost.html) (mpost - binary), usually packaged with TeX + 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/) (4.11 or newer) + • Texinfo (http://www.gnu.org/software/texinfo/) - * Type 1 utilities (http://www.lcdf.org/~eddietwo/type/#t1utils) - (1.33 or newer recommended) + Use version ‘4.11’ or newer. -Requirements for building documentation ---------------------------------------- + • Type 1 utilities (http://www.lcdf.org/~eddietwo/type/#t1utils) -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: + Use version ‘1.33’ or newer. - * Everything listed in *note Requirements for compiling LilyPond:: + • Cyrillic fonts (https://www.ctan.org/pkg/cyrillic?lang=en) - * ImageMagick (http://www.imagemagick.org/) + Often packaged in repositories as ‘texlive-lang-cyrillic’. - * Netpbm (http://netpbm.sourceforge.net/) + • 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::. - * gzip (http://gzip.org/) + 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. - * rsync (http://rsync.samba.org/) + The following font families are required: - * Texi2HTML (http://www.nongnu.org/texi2html/) (1.82) + 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). - * International fonts +1.2.3 Requirements for building documentation +--------------------------------------------- - Red Hat Fedora: +The entire set of documentation for the most current build of LilyPond +is available online at +, but you +can also build them locally from the source code. This process requires +some additional tools and packages. - fonts-arabic - fonts-hebrew - fonts-ja - fonts-xorg-truetype - taipeifonts - ttfonts-ja - ttfonts-zh_CN + 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. - Debian GNU/Linux: + • Everything listed in *note Requirements for compiling LilyPond:: - emacs-intl-fonts - ttf-kochi-gothic - ttf-kochi-mincho - xfonts-bolkhov-75dpi - xfonts-cronyx-75dpi - xfonts-cronyx-100dpi - xfonts-intl-.* + • ImageMagick (http://www.imagemagick.org/) + + • Netpbm (http://netpbm.sourceforge.net/) + + • gzip (http://gzip.org/) + + • rsync (http://rsync.samba.org/) + + • Texi2HTML (http://www.nongnu.org/texi2html/) + + Use version ‘1.82’. Later versions will not work. + + Download ‘texi2html 1.82’ directly from: + ; + + Extract the files into an appropriate location and then run the + commands; + + ./configure + make + sudo make install + + Now verify that your operating system is able to see the correct + version of ‘texi2html’. -Getting the source code -======================= + 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 +=========================== Downloading the Git repository ------------------------------ 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 ---------------------------- @@ -218,7 +501,7 @@ 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 @@ -227,14 +510,14 @@ 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 + 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: @@ -242,23 +525,23 @@ appropriate place. 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. -Configuring `make' -================== +1.4 Configuring ‘make’ +====================== -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'. +. Next, you need to create the generated files; enter the following command from your top source directory: @@ -266,7 +549,7 @@ 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: @@ -276,32 +559,32 @@ configuration, such as `configure', `README.txt', etc. We heavily recommend building lilypond inside a separate directory with this method. -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 @@ -313,7 +596,7 @@ only needed for building the documentation: 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 @@ -322,85 +605,91 @@ install or update these programs accordingly. 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::. -Compiling LilyPond -================== +1.5 Compiling LilyPond +====================== -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’ +targets used to build the LilyPond documentation. -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. -Compiling for multiple platforms --------------------------------- +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 @@ -412,8 +701,8 @@ profiling, then use the following for the normal build --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 @@ -421,34 +710,32 @@ forget to use `conf=CONF' when issuing `make install': See also ........ - - *note Installing LilyPond from a local build:: -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. -Post-compilation options -======================== +1.6 Post-compilation options +============================ -Installing LilyPond from a local build --------------------------------------- +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 @@ -456,123 +743,140 @@ or... 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::. -Generating documentation ------------------------- +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 _## 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..._ 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: - - In some cases, it is possible to clean the compiled documentation - with `make doc-clean', but this method is not guaranteed to fix - everything. Instead, 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. + • Reset: + It is generally possible to remove the compiled documentation from + 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 + 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. 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 - 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. + or, to build only the PDF documentation and not the HTML, + + make doc-stage-1 + + Note: The first time you run ‘make doc’, the process can + easily take an hour or more with not much output on the + command line. - 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' + After this initial build, ‘make doc’ only makes changes to the +documentation where needed, so it may only take a minute or two to test +changes if the documentation is already built. + + If ‘make doc’ succeeds, the HTML documentation tree is available in +‘out-www/offline-root/’, and can be browsed locally. Various portions +of the documentation can be found by looking in ‘out/’ and ‘out-www’ subdirectories in other places in the source tree, but these are only _portions_ of the docs. Please do not complain about anything which is broken in those places; the only complete set of documentation is in -`out-www/offline-root/' from the top of the source tree. +‘out-www/offline-root/’ from the top of the source tree. + + ‘make doc’ sends the output from most of the compilation to logfiles. +If the build fails for any reason, it should prompt you with the name of +a logfile which will provide information to help you work out why the +build failed. These logfiles are not deleted with ‘make doc-clean’. To +remove all the logfiles generated by the compilation process, use: + + make log-clean + + ‘make doc’ compiles the documents for all languages. To save some +compile time, the English language documents can be compiled on their +own with: + + make LANGS='' doc + +Similarly, it is possible to compile a subset of the translated +documentation by specifying their language codes on the command line. +For example, the French and German translations are compiled with: + + make LANGS='de fr' doc + +Note that this will also compile the English version. Compilation of documentation in Info format with images can be done separately by issuing: make info +An issue when switching branches between master and translation is the +appearance/disappearance of translated versions of some manuals. If you +see such a warning from make: -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 + No rule to make target `X', needed by `Y' -The top sources possibly affected by this are: +Your best bet is to delete the file Y.dep and to try again. - 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 +Building a single document +.......................... -You can `touch' all of them at once with: +It’s possible to build a single document. For example, to rebuild only +‘contributor.pdf’, do the following: - touch Documentation/*te?? + cd build/ + cd Documentation/ + touch ../../Documentation/contributor.texi + make out=www out-www/contributor.pdf -However, this will rebuild all of the manuals indiscriminately--it is -more efficient to `touch' only the affected files. + 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. -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 ........... @@ -604,19 +908,19 @@ installation of Info documentation are printed on standard output. 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 @@ -627,10 +931,10 @@ available with 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 @@ -646,14 +950,14 @@ binary, if LilyPond is already installed on your system. 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 @@ -663,7 +967,7 @@ 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 @@ -679,8 +983,8 @@ exec /sw/bin/pngtopnm "$@" export DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib exec /opt/local/bin/pngtopnm "$@" -Testing LilyPond binary ------------------------ +1.6.3 Testing LilyPond binary +----------------------------- LilyPond comes with an extensive suite that exercises the entire program. This suite can be used to test that the binary has been built @@ -694,33 +998,20 @@ make test been verified. More information on the regression test suite is found at *note -Regression tests: (lilypond-contributor)Regression tests. +(lilypond-contributor)Regression tests::. -Problems -======== +1.7 Problems +============ -For help and questions use . Send bug reports -to . +For help and questions use . Send bug reports to +. 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). @@ -728,13 +1019,13 @@ instructions assume that dependencies are installed using MacPorts. 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 @@ -743,9 +1034,9 @@ 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 +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: @@ -753,18 +1044,18 @@ 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 @@ -774,24 +1065,24 @@ or CONFIG_SHELL=/bin/bash bash -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 `' line. (Adjust as necessary + Open the file ‘$LILYPONDBASE/usr/etc/fonts/local.conf’ and add the +following line just after the ‘’ line. (Adjust as necessary for your hierarchy.) /usr/X11R6/lib/X11/fonts 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 (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 @@ -806,48 +1097,48 @@ Red Hat Fedora 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. -Concurrent stable and development versions -========================================== +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: /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 /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 @@ -859,25 +1150,24 @@ stable `lilypond'), and make it executable: - other compilation tricks for developers -Build system -============ +1.9 Build system +================ We currently use make and stepmake, which is complicated and only used by us. Hopefully this will change in the future. Version-specific texinfo macros -............................... +------------------------------- - * 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. -