1 INSTALL - compiling and installing GNU LilyPond
2 ***********************************************
7 INSTALL - compiling and installing GNU LilyPond
9 1.1 Overview of compiling
11 1.2.1 Requirements for running LilyPond
12 1.2.2 Requirements for compiling LilyPond
13 1.2.3 Requirements for building documentation
14 1.3 Getting the source code
15 1.4 Configuring `make'
16 1.4.1 Running `./autogen.sh'
17 1.4.2 Running `../configure'
19 Checking build dependencies
20 Configuring target directories
21 1.5 Compiling LilyPond
23 1.5.2 Saving time with the `-j' option
24 1.5.3 Compiling for multiple platforms
25 1.5.4 Useful `make' variables
26 1.6 Post-compilation options
27 1.6.1 Installing LilyPond from a local build
28 1.6.2 Generating documentation
29 Documentation editor's edit/compile cycle
30 Building documentation
31 Building a single document
32 Saving time with `CPU_COUNT'
34 Installing documentation
35 Building documentation without compiling
36 1.6.3 Testing LilyPond binary
43 Using lilypond python libraries
44 1.8 Concurrent stable and development versions
51 1.1 Overview of compiling
52 =========================
54 Compiling LilyPond from source is an involved process, and is only
55 recommended for developers and packagers. Typical program users are
56 instead encouraged to obtain the program from a package manager (on
57 Unix) or by downloading a precompiled binary configured for a specific
58 operating system. Pre-compiled binaries are available on the *note
59 Download: (lilypond-web)Download. page.
61 Compiling LilyPond from source is necessary if you want to build,
62 install, or test your own version of the program.
64 A successful compile can also be used to generate and install the
65 documentation, incorporating any changes you may have made. However, a
66 successful compile is not a requirement for generating the
67 documentation. The documentation can be built using a Git repository
68 in conjunction with a locally installed copy of the program. For more
69 information, see *note Building documentation without compiling::.
71 Attempts to compile LilyPond natively on Windows have been
72 unsuccessful, though a workaround is available (see *note LilyDev:
73 (lilypond-contributor)LilyDev.).
78 1.2.1 Requirements for running LilyPond
79 ---------------------------------------
81 Running LilyPond requires proper installation of the following software:
83 * DejaVu fonts (http://www.dejavu-fonts.org/) (normally installed by
86 * FontConfig (http://www.fontconfig.org/) (2.4.0 or newer)
88 * Freetype (http://www.freetype.org/) (2.1.10 or newer)
90 * Ghostscript (http://www.ghostscript.com) (8.60 or newer)
92 * Guile (http://www.gnu.org/software/guile/guile.html) (1.8.2 or
95 * Pango (http://www.pango.org/) (1.12 or newer)
97 * Python (http://www.python.org) (2.4 or newer)
99 International fonts are required to create music with international
102 1.2.2 Requirements for compiling LilyPond
103 -----------------------------------------
105 Below is a full list of packages needed to build LilyPond. However,
106 for most common distributions there is an easy way of installing most
107 all build dependencies in one go:
110 --------------------------------------------------------------------------
111 Debian, Ubuntu `sudo apt-get build-dep lilypond'
112 Fedora, RHEL `sudo yum-builddep lilypond'
113 openSUSE, SLED `sudo zypper --build-deps-only
114 source-install lilypond'
116 * Everything listed in *note Requirements for running LilyPond::
118 * Development packages for the above items (which should include
119 header files and libraries).
124 fontconfig-devel-VERSION
125 freetype-devel-VERSION
137 * Flex (http://flex.sourceforge.net/)
139 * FontForge (http://fontforge.sf.net/) (20060125 or newer; 20100501
140 or newer is recommended; must be compiled with `--enable-double'.
141 Failure to do so can lead to poor intersection calculations and
142 poorly-rendered glyphs.)
144 * GNU Bison (http://www.gnu.org/software/bison/)
146 * GNU Compiler Collection (http://gcc.gnu.org/) (3.4 or newer, 4.X
149 * GNU gettext (http://www.gnu.org/software/gettext/gettext.html)
152 * GNU Make (http://www.gnu.org/software/make/) (3.78 or newer)
154 * MetaFont (http://metafont.tutorial.free.fr/) (mf-nowin, mf, mfw or
155 mfont binaries), usually packaged with TeX
156 (http://www.latex-project.org/ftp.html).
158 * MetaPost (http://cm.bell-labs.com/who/hobby/MetaPost.html) (mpost
159 binary), usually packaged with TeX
160 (http://www.latex-project.org/ftp.html).
162 * Perl (http://www.perl.org/)
164 * Texinfo (http://www.gnu.org/software/texinfo/) (4.11 or newer)
166 * Type 1 utilities (http://www.lcdf.org/~eddietwo/type/#t1utils)
167 (1.33 or newer recommended)
169 1.2.3 Requirements for building documentation
170 ---------------------------------------------
172 You can view the documentation online at
173 `http://www.lilypond.org/doc/', but you can also build it locally.
174 This process requires some additional tools and packages:
176 * Everything listed in *note Requirements for compiling LilyPond::
178 * ImageMagick (http://www.imagemagick.org/)
180 * Netpbm (http://netpbm.sourceforge.net/)
182 * gzip (http://gzip.org/)
184 * rsync (http://rsync.samba.org/)
186 * Texi2HTML (http://www.nongnu.org/texi2html/) (1.82)
188 * International fonts
210 1.3 Getting the source code
211 ===========================
213 Downloading the Git repository
214 ------------------------------
216 In general, developers compile LilyPond from within a local Git
217 repository. Setting up a local Git repository is explained in *note
218 Starting with Git: (lilypond-contributor)Starting with Git.
220 Downloading a source tarball
221 ----------------------------
223 Packagers are encouraged to use source tarballs for compiling.
225 The tarball for the latest stable release is available on the *note
226 Source: (lilypond-web)Source. page.
228 The latest source code snapshot
229 (http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=snapshot) is also
230 available as a tarball from the GNU Savannah Git server.
232 All tagged releases (including legacy stable versions and the most
233 recent development release) are available here:
235 `http://download.linuxaudio.org/lilypond/source/'
237 Download the tarball to your `~/src/' directory, or some other
240 Note: Be careful where you unpack the tarball! Any
241 subdirectories of the current folder named `lilypond/' or
242 `lilypond-X.Y.Z/' (where X.Y.Z is the release number) will be
243 overwritten if there is a name clash with the tarball.
245 Unpack the tarball with this command:
247 tar -xzf lilypond-X.Y.Z.tar.gz
249 This creates a subdirectory within the current directory called
250 `lilypond-X.Y.Z/'. Once unpacked, the source files occupy about 40 MB
253 Windows users wanting to look at the source code may have to
254 download and install the free-software 7zip archiver
255 (http://www.7-zip.org) to extract the tarball.
257 1.4 Configuring `make'
258 ======================
260 1.4.1 Running `./autogen.sh'
261 ----------------------------
263 After you unpack the tarball (or download the Git repository), the
264 contents of your top source directory should be similar to the current
265 source tree listed at
266 `http://git.sv.gnu.org/gitweb/?p=lilypond.git;a=tree'.
268 Next, you need to create the generated files; enter the following
269 command from your top source directory:
271 ./autogen.sh --noconfigure
273 This will generate a number of files and directories to aid
274 configuration, such as `configure', `README.txt', etc.
276 Next, create the build directory with:
281 We heavily recommend building lilypond inside a separate directory
284 1.4.2 Running `../configure'
285 ----------------------------
287 Configuration options
288 .....................
290 Note: make sure that you are in the `build/' subdirectory of
293 The `../configure' command (generated by `./autogen.sh') provides many
294 options for configuring `make'. To see them all, run:
298 Checking build dependencies
299 ...........................
301 Note: make sure that you are in the `build/' subdirectory of
304 When `../configure' is run without any arguments, it will check to make
305 sure your system has everything required for compilation:
309 If any build dependency is missing, `../configure' will return with:
311 ERROR: Please install required programs: FOO
313 The following message is issued if you are missing programs that are
314 only needed for building the documentation:
316 WARNING: Please consider installing optional programs: BAR
318 If you intend to build the documentation locally, you will need to
319 install or update these programs accordingly.
321 Note: `../configure' may fail to issue warnings for certain
322 documentation build requirements that are not met. If you
323 experience problems when building the documentation, you may
324 need to do a manual check of *note Requirements for building
327 Configuring target directories
328 ..............................
330 Note: make sure that you are in the `build/' subdirectory of
333 If you intend to use your local build to install a local copy of the
334 program, you will probably want to configure the installation
335 directory. Here are the relevant lines taken from the output of
336 `../configure --help':
338 By default, ``make install'' will install all the files in
339 `/usr/local/bin', `/usr/local/lib' etc. You can specify an
340 installation prefix other than `/usr/local' using ``--prefix'',
341 for instance ``--prefix=$HOME''.
343 A typical installation prefix is `$HOME/usr':
345 ../configure --prefix=$HOME/usr
347 Note that if you plan to install a local build on a system where you
348 do not have root privileges, you will need to do something like this
349 anyway--`make install' will only succeed if the installation prefix
350 points to a directory where you have write permission (such as your
351 home directory). The installation directory will be automatically
352 created if necessary.
354 The location of the `lilypond' command installed by this process
355 will be `PREFIX/bin/lilypond'; you may want to add `PREFIX/bin/' to
356 your `$PATH' if it is not already included.
358 It is also possible to specify separate installation directories for
359 different types of program files. See the full output of
360 `../configure --help' for more information.
362 If you encounter any problems, please see *note Problems::.
364 1.5 Compiling LilyPond
365 ======================
370 Note: make sure that you are in the `build/' subdirectory of
373 LilyPond is compiled with the `make' command. Assuming `make' is
374 configured properly, you can simply run:
378 `make' is short for `make all'. To view a list of `make' targets,
383 TODO: Describe what `make' actually does.
392 *note Generating documentation:: provides more info on the `make'
393 targets used to build the LilyPond documentation.
395 1.5.2 Saving time with the `-j' option
396 --------------------------------------
398 If your system has multiple CPUs, you can speed up compilation by
399 adding `-jX' to the `make' command, where `X' is one more than the
400 number of cores you have. For example, a typical Core2Duo machine
405 If you get errors using the `-j' option, and `make' succeeds without
406 it, try lowering the `X' value.
408 Because multiple jobs run in parallel when `-j' is used, it can be
409 difficult to determine the source of an error when one occurs. In that
410 case, running `make' without the `-j' is advised.
412 1.5.3 Compiling for multiple platforms
413 --------------------------------------
415 If you want to build multiple versions of LilyPond with different
416 configuration settings, you can use the `--enable-config=CONF' option
417 of `configure'. You should use `make conf=CONF' to generate the output
418 in `out-CONF'. For example, suppose you want to build with and without
419 profiling, then use the following for the normal build
421 ./configure --prefix=$HOME/usr/ --enable-checking
424 and for the profiling version, specify a different configuration
426 ./configure --prefix=$HOME/usr/ --enable-profiling \
427 --enable-config=prof --disable-checking
430 If you wish to install a copy of the build with profiling, don't
431 forget to use `conf=CONF' when issuing `make install':
433 make conf=prof install
441 *note Installing LilyPond from a local build::
443 1.5.4 Useful `make' variables
444 -----------------------------
446 If a less verbose build output if desired, the variable `QUIET_BUILD'
447 may be set to `1' on `make' command line, or in `local.make' at top of
450 1.6 Post-compilation options
451 ============================
453 1.6.1 Installing LilyPond from a local build
454 --------------------------------------------
456 If you configured `make' to install your local build in a directory
457 where you normally have write permission (such as your home directory),
458 and you have compiled LilyPond by running `make', you can install the
459 program in your target directory by running:
463 If instead, your installation directory is not one that you can
464 normally write to (such as the default `/usr/local/', which typically
465 is only writeable by the superuser), you will need to temporarily
466 become the superuser when running `make install':
474 If you don't have superuser privileges, then you need to configure
475 the installation directory to one that you can write to, and then
476 re-install. See *note Configuring target directories::.
478 1.6.2 Generating documentation
479 ------------------------------
481 Documentation editor's edit/compile cycle
482 .........................................
484 * Initial documentation build:
487 make [-jX CPU_COUNT=X] doc _## can take an hour or more_
488 make [-jX CPU_COUNT=X] doc-stage-1 _## to build only PDF documentation_
490 * Edit/compile cycle:
492 _## edit source files, then..._
494 make [-jX] _## needed if editing outside_
495 _## Documentation/, but useful anyway_
496 _## for finding Texinfo errors._
497 make [-jX CPU_COUNT=X] doc _## usually faster than initial build._
501 It is generally possible to remove the compiled documentation from
502 your system with `make doc-clean', but this method is not 100%
503 guaranteed. Instead, if you want to be sure you have a clean
504 system, we recommend that you delete your `build/' directory, and
505 begin compiling from scratch. Since the documentation compile
506 takes much longer than the non-documentation compile, this does
507 not increase the overall time by a great deal.
510 Building documentation
511 ......................
513 After a successful compile (using `make'), the documentation can be
518 or, to build only the PDF documentation and not the HTML,
522 Note: The first time you run `make doc', the process can
523 easily take an hour or more with not much output on the
526 After this initial build, `make doc' only makes changes to the
527 documentation where needed, so it may only take a minute or two to test
528 changes if the documentation is already built.
530 If `make doc' succeeds, the HTML documentation tree is available in
531 `out-www/offline-root/', and can be browsed locally. Various portions
532 of the documentation can be found by looking in `out/' and `out-www'
533 subdirectories in other places in the source tree, but these are only
534 _portions_ of the docs. Please do not complain about anything which is
535 broken in those places; the only complete set of documentation is in
536 `out-www/offline-root/' from the top of the source tree.
538 `make doc' sends the output from most of the compilation to
539 logfiles. If the build fails for any reason, it should prompt you with
540 the name of a logfile which will provide information to help you work
541 out why the build failed. These logfiles are not deleted with
542 `make doc-clean'. To remove all the logfiles generated by the
543 compilation process, use:
547 `make doc' compiles the documents for all languages. To save some
548 compile time, the English language documents can be compiled on their
553 Similarly, it is possible to compile a subset of the translated
554 documentation by specifying their language codes on the command line.
555 For example, the French and German translations are compiled with:
557 make LANGS='de fr' doc
559 Note that this will also compile the English version.
561 Compilation of documentation in Info format with images can be done
562 separately by issuing:
566 An issue when switching branches between master and translation is the
567 appearance/disappearance of translated versions of some manuals. If
568 you see such a warning from make:
570 No rule to make target `X', needed by `Y'
572 Your best bet is to delete the file Y.dep and to try again.
574 Building a single document
575 ..........................
577 It's possible to build a single document. For example, to rebuild only
578 `contributor.pdf', do the following:
582 touch ../../Documentation/contributor.texi
583 make out=www out-www/contributor.pdf
585 If you are only working on a single document, test-building it in
586 this way can give substantial time savings - recreating
587 `contributor.pdf', for example, takes a matter of seconds.
589 Saving time with `CPU_COUNT'
590 ............................
592 The most time consuming task for building the documentation is running
593 LilyPond to build images of music, and there cannot be several
594 simultaneously running `lilypond-book' instances, so the `-j' `make'
595 option does not significantly speed up the build process. To help
596 speed it up, the makefile variable `CPU_COUNT' may be set in
597 `local.make' or on the command line to the number of `.ly' files that
598 LilyPond should process simultaneously, e.g. on a bi-processor or dual
601 make -j3 CPU_COUNT=3 doc
603 The recommended value of `CPU_COUNT' is one plus the number of cores or
604 processors, but it is advisable to set it to a smaller value unless
605 your system has enough RAM to run that many simultaneous LilyPond
606 instances. Also, values for the `-j' option that pose problems with
607 `make' are less likely to pose problems with `make doc' (this applies
608 to both `-j' and `CPU_COUNT'). For example, with a quad-core processor,
609 it is possible for `make -j5 CPU_COUNT=5 doc' to work consistently even
610 if `make -j5' rarely succeeds.
615 To build the documentation with interactive searching, use:
617 make doc AJAX_SEARCH=1
619 This requires PHP, and you must view the docs via a http connection
620 (you cannot view them on your local filesystem).
622 Note: Due to potential security or load issues, this option is
623 not enabled in the official documentation builds. Enable at
626 Installing documentation
627 ........................
629 The HTML, PDF and if available Info files can be installed into the
630 standard documentation path by issuing
634 This also installs Info documentation with images if the installation
635 prefix is properly set; otherwise, instructions to complete proper
636 installation of Info documentation are printed on standard output.
638 To install the Info documentation separately, run:
642 Note that to get the images in Info documentation, `install-doc' target
643 creates symbolic links to HTML and PDF installed documentation tree in
644 `PREFIX/share/info', in order to save disk space, whereas
645 `install-info' copies images in `PREFIX/share/info' subdirectories.
647 It is possible to build a documentation tree in
648 `out-www/online-root/', with special processing, so it can be used on a
649 website with content negotiation for automatic language selection; this
650 can be achieved by issuing
652 make WEB_TARGETS=online doc
654 and both `offline' and `online' targets can be generated by issuing
656 make WEB_TARGETS="offline online" doc
658 Several targets are available to clean the documentation build and
659 help with maintaining documentation; an overview of these targets is
664 from every directory in the build tree. Most targets for documentation
665 maintenance are available from `Documentation/'; for more information,
666 see *note Documentation work: (lilypond-contributor)Documentation work.
668 The makefile variable `QUIET_BUILD' may be set to `1' for a less
669 verbose build output, just like for building the programs.
671 Building documentation without compiling
672 ........................................
674 The documentation can be built locally without compiling LilyPond
675 binary, if LilyPond is already installed on your system.
677 From a fresh Git checkout, do
679 ./autogen.sh # ignore any warning messages
680 cp GNUmakefile.in GNUmakefile
681 make -C scripts && make -C python
682 nice make LILYPOND_EXTERNAL_BINARY=/path/to/bin/lilypond doc
684 Please note that this may break sometimes - for example, if a new
685 feature is added with a test file in input/regression, even the latest
686 development release of LilyPond will fail to build the docs.
688 You may build the manual without building all the `input/*' stuff
689 (i.e. mostly regression tests): change directory, for example to
690 `Documentation/', issue `make doc', which will build documentation in a
691 subdirectory `out-www' from the source files in current directory. In
692 this case, if you also want to browse the documentation in its
693 post-processed form, change back to top directory and issue
695 make out=www WWW-post
698 Known issues and warnings
699 .........................
701 You may also need to create a script for `pngtopnm' and `pnmtopng'. On
702 GNU/Linux, I use this:
704 export LD_LIBRARY_PATH=/usr/lib
705 exec /usr/bin/pngtopnm "$@"
707 On MacOS X with fink, I use this:
709 export DYLD_LIBRARY_PATH=/sw/lib
710 exec /sw/bin/pngtopnm "$@"
712 On MacOS X with macports, you should use this:
714 export DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib
715 exec /opt/local/bin/pngtopnm "$@"
717 1.6.3 Testing LilyPond binary
718 -----------------------------
720 LilyPond comes with an extensive suite that exercises the entire
721 program. This suite can be used to test that the binary has been built
724 The test suite can be executed with:
728 If the test suite completes successfully, the LilyPond binary has
731 More information on the regression test suite is found at *note
732 Regression tests: (lilypond-contributor)Regression tests.
737 For help and questions use <lilypond-user@gnu.org>. Send bug reports
738 to <bug-lilypond@gnu.org>.
740 Bugs that are not fault of LilyPond are documented here.
745 There is a bug in bison-1.875: compilation fails with "parse error
746 before `goto'" in line 4922 due to a bug in bison. To fix, please
747 recompile bison 1.875 with the following fix
749 $ cd lily; make out/parser.cc
750 $ vi +4919 out/parser.cc
751 # append a semicolon to the line containing "__attribute__ ((__unused__))
758 Here are special instructions for compiling under MacOS X. These
759 instructions assume that dependencies are installed using MacPorts.
760 (http://www.macports.org/) The instructions have been tested using OS X
763 First, install the relevant dependencies using MacPorts.
765 Next, add the following to your relevant shell initialization files.
766 This is `~/.profile' by default. You should create this file if it
769 export PATH=/opt/local/bin:/opt/local/sbin:$PATH
770 export DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib:$DYLD_FALLBACK_LIBRARY_PATH
772 Now you must edit the generated `config.make' file. Change
774 FLEXLEXER_FILE = /usr/include/FlexLexer.h
778 FLEXLEXER_FILE = /opt/local/include/FlexLexer.h
780 At this point, you should verify that you have the appropriate fonts
781 installed with your ghostscript installation. Check `ls
782 /opt/local/share/ghostscript/fonts' for: 'c0590*' files (.pfb, .pfb and
783 .afm). If you don't have them, run the following commands to grab them
784 from the ghostscript SVN server and install them in the appropriate
787 svn export http://svn.ghostscript.com/ghostscript/tags/urw-fonts-1.0.7pre44/
788 sudo mv urw-fonts-1.0.7pre44/* /opt/local/share/ghostscript/fonts/
789 rm -rf urw-fonts-1.07pre44
791 Now run the `./configure' script. To avoid complications with
792 automatic font detection, add
794 --with-ncsb-dir=/opt/local/share/ghostscript/fonts
799 Solaris7, ./configure
801 `./configure' needs a POSIX compliant shell. On Solaris7, `/bin/sh'
802 is not yet POSIX compliant, but `/bin/ksh' or bash is. Run configure
805 CONFIG_SHELL=/bin/ksh ksh -c ./configure
809 CONFIG_SHELL=/bin/bash bash -c ./configure
814 To use system fonts, dejaview must be installed. With the default
815 port, the fonts are installed in `usr/X11R6/lib/X11/fonts/dejavu'.
817 Open the file `$LILYPONDBASE/usr/etc/fonts/local.conf' and add the
818 following line just after the `<fontconfig>' line. (Adjust as necessary
821 <dir>/usr/X11R6/lib/X11/fonts</dir>
826 On Mac OS X, all fonts are installed by default. However, finding all
827 system fonts requires a bit of configuration; see this post
828 (http://lists.gnu.org/archive/html/lilypond-user/2007-03/msg00472.html)
829 on the `lilypond-user' mailing list.
831 On Linux, international fonts are installed by different means on
832 every distribution. We cannot list the exact commands or packages that
833 are necessary, as each distribution is different, and the exact package
834 names within each distribution changes. Here are some hints, though:
838 taipeifonts fonts-xorg-truetype ttfonts-ja fonts-arabic \
839 ttfonts-zh_CN fonts-ja fonts-hebrew
843 apt-get install emacs-intl-fonts xfonts-intl-.* \
844 ttf-kochi-gothic ttf-kochi-mincho \
845 xfonts-bolkhov-75dpi xfonts-cronyx-100dpi xfonts-cronyx-75dpi
847 Using lilypond python libraries
848 -------------------------------
850 If you want to use lilypond's python libraries (either running certain
851 build scripts manually, or using them in other programs), set
852 `PYTHONPATH' to `python/out' in your build directory, or
853 `.../usr/lib/lilypond/current/python' in the installation directory
856 1.8 Concurrent stable and development versions
857 ==============================================
859 It can be useful to have both the stable and the development versions
860 of Lilypond available at once. One way to do this on GNU/Linux is to
861 install the stable version using the precompiled binary, and run the
862 development version from the source tree. After running `make all'
863 from the top directory of the Lilypond source files, there will be a
864 binary called `lilypond' in the `out' directory:
866 <PATH TO>/lilypond/out/bin/lilypond
868 This binary can be run without actually doing the `make install'
869 command. The advantage to this is that you can have all of the latest
870 changes available after pulling from git and running `make all',
871 without having to uninstall the old version and reinstall the new.
873 So, to use the stable version, install it as usual and use the
878 To use the development version, create a link to the binary in the
879 source tree by saving the following line in a file somewhere in your
882 exec <PATH TO>/lilypond/out/bin/lilypond "$@"
884 Save it as `Lilypond' (with a capital L to distinguish it from the
885 stable `lilypond'), and make it executable:
889 Then you can invoke the development version this way:
895 - other compilation tricks for developers
900 We currently use make and stepmake, which is complicated and only used
901 by us. Hopefully this will change in the future.
903 Version-specific texinfo macros
904 -------------------------------
906 * made with `scripts/build/create-version-itexi.py' and
907 `scripts/build/create-weblinks-itexi.py'
909 * used extensively in the `WEBSITE_ONLY_BUILD' version of the
910 website (made with `website.make', used on lilypond.org)
912 * not (?) used in the main docs?
914 * the numbers in VERSION file: MINOR_VERSION should be 1 more than
915 the last release, VERSION_DEVEL should be the last *online*
916 release. Yes, VERSION_DEVEL is less than VERSION.
projects / lilypond.git / blob