+ TODO: Describe what ‘make’ actually does.
+
+
+See also
+........
+
+ *note Generating documentation:: provides more info on the ‘make’
+targets used to build the LilyPond documentation.
+
+1.5.2 Saving time with the ‘-j’ option
+--------------------------------------
+
+If your system has multiple CPUs, you can speed up compilation by adding
+‘-jX’ to the ‘make’ command, where ‘X’ is one more than the number of
+cores you have. For example, a typical Core2Duo machine would use:
+
+ make -j3
+
+ If you get errors using the ‘-j’ option, and ‘make’ succeeds without
+it, try lowering the ‘X’ value.
+
+ Because multiple jobs run in parallel when ‘-j’ is used, it can be
+difficult to determine the source of an error when one occurs. In that
+case, running ‘make’ without the ‘-j’ is advised.
+
+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
+profiling, then use the following for the normal build
+
+ ./configure --prefix=$HOME/usr/ --enable-checking
+ make
+
+ and for the profiling version, specify a different configuration
+
+ ./configure --prefix=$HOME/usr/ --enable-profiling \
+ --enable-config=prof --disable-checking
+ make conf=prof
+
+ If you wish to install a copy of the build with profiling, don’t
+forget to use ‘conf=CONF’ when issuing ‘make install’:
+
+ make conf=prof install
+
+
+See also
+........
+
+ *note Installing LilyPond from a local build::
+
+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
+the build tree.
+
+1.6 Post-compilation options
+============================
+
+1.6.1 Installing LilyPond from a local build
+--------------------------------------------
+
+If you configured ‘make’ to install your local build in a directory
+where you normally have write permission (such as your home directory),
+and you have compiled LilyPond by running ‘make’, you can install the
+program in your target directory by running:
+
+ make install
+
+ If instead, your installation directory is not one that you can
+normally write to (such as the default ‘/usr/local/’, which typically is
+only writeable by the superuser), you will need to temporarily become
+the superuser when running ‘make install’:
+
+ sudo make install
+
+or...
+
+ su -c 'make install'
+
+ If you don’t have superuser privileges, then you need to configure
+the installation directory to one that you can write to, and then
+re-install. See *note Configuring target directories::.
+
+1.6.2 Generating documentation
+------------------------------
+
+Documentation editor’s edit/compile cycle
+.........................................
+
+ • Initial documentation build:
+
+ make [-jX]
+ make [-jX CPU_COUNT=X] doc _## can take an hour or more_
+ make [-jX CPU_COUNT=X] doc-stage-1 _## to build only PDF documentation_
+
+ • Edit/compile cycle:
+
+ _## edit source files, then..._
+
+ make [-jX] _## needed if editing outside_
+ _## Documentation/, but useful anyway_
+ _## for finding Texinfo errors._
+ make [-jX CPU_COUNT=X] doc _## usually faster than initial build._
+
+ • 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
+built by issuing:
+
+ make doc
+
+ 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.
+
+ 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.
+
+ ‘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:
+
+ No rule to make target `X', needed by `Y'
+
+Your best bet is to delete the file Y.dep and to try again.
+
+Building a single document
+..........................
+
+It’s possible to build a single document. For example, to rebuild only
+‘contributor.pdf’, do the following:
+
+ cd build/
+ cd Documentation/
+ touch ../../Documentation/contributor.texi
+ make out=www out-www/contributor.pdf
+
+ 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’
+............................
+
+The most time consuming task for building the documentation is running
+LilyPond to build images of music, and there cannot be several
+simultaneously running ‘lilypond-book’ instances, so the ‘-j’ ‘make’
+option does not significantly speed up the build process. To help speed
+it up, the makefile variable ‘CPU_COUNT’ may be set in ‘local.make’ or
+on the command line to the number of ‘.ly’ files that LilyPond should
+process simultaneously, e.g. on a bi-processor or dual core machine:
+
+ make -j3 CPU_COUNT=3 doc
+
+The recommended value of ‘CPU_COUNT’ is one plus the number of cores or
+processors, but it is advisable to set it to a smaller value unless your
+system has enough RAM to run that many simultaneous LilyPond instances.
+Also, values for the ‘-j’ option that pose problems with ‘make’ are less
+likely to pose problems with ‘make doc’ (this applies to both ‘-j’ and
+‘CPU_COUNT’). For example, with a quad-core processor, it is possible
+for ‘make -j5 CPU_COUNT=5 doc’ to work consistently even if ‘make -j5’
+rarely succeeds.
+
+AJAX search
+...........
+
+To build the documentation with interactive searching, use:
+
+ make doc AJAX_SEARCH=1
+
+ This requires PHP, and you must view the docs via a http connection
+(you cannot view them on your local filesystem).
+
+ Note: Due to potential security or load issues, this option is
+ not enabled in the official documentation builds. Enable at
+ your own risk.
+
+Installing documentation
+........................
+
+The HTML, PDF and if available Info files can be installed into the
+standard documentation path by issuing
+
+ make install-doc
+
+This also installs Info documentation with images if the installation
+prefix is properly set; otherwise, instructions to complete proper
+installation of Info documentation are printed on standard output.
+
+ To install the Info documentation separately, run:
+
+ make install-info
+
+Note that to get the images in Info documentation, ‘install-doc’ target
+creates symbolic links to HTML and PDF installed documentation tree in
+‘PREFIX/share/info’, in order to save disk space, whereas ‘install-info’
+copies images in ‘PREFIX/share/info’ subdirectories.
+
+ It is possible to build a documentation tree in
+‘out-www/online-root/’, with special processing, so it can be used on a
+website with content negotiation for automatic language selection; this
+can be achieved by issuing
+
+ make WEB_TARGETS=online doc
+
+and both ‘offline’ and ‘online’ targets can be generated by issuing
+
+ make WEB_TARGETS="offline online" doc
+
+ Several targets are available to clean the documentation build and
+help with maintaining documentation; an overview of these targets is
+available with
+
+ make help
+
+from every directory in the build tree. Most targets for documentation
+maintenance are available from ‘Documentation/’; for more information,
+see *note (lilypond-contributor)Documentation work::.
+
+ 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
+........................................
+
+The documentation can be built locally without compiling LilyPond
+binary, if LilyPond is already installed on your system.
+
+ From a fresh Git checkout, do
+
+ ./autogen.sh # ignore any warning messages
+ cp GNUmakefile.in GNUmakefile
+ make -C scripts && make -C python
+ nice make LILYPOND_EXTERNAL_BINARY=/path/to/bin/lilypond doc
+
+ Please note that this may break sometimes – for example, if a new
+feature is added with a test file in input/regression, even the latest
+development release of LilyPond will fail to build the docs.
+
+ You may build the manual without building all the ‘input/*’ stuff
+(i.e. mostly regression tests): change directory, for example to
+‘Documentation/’, issue ‘make doc’, which will build documentation in a
+subdirectory ‘out-www’ from the source files in current directory. In
+this case, if you also want to browse the documentation in its
+post-processed form, change back to top directory and issue
+
+ make out=www WWW-post
+
+
+Known issues and warnings
+.........................
+
+You may also need to create a script for ‘pngtopnm’ and ‘pnmtopng’. On
+GNU/Linux, I use this:
+
+export LD_LIBRARY_PATH=/usr/lib
+exec /usr/bin/pngtopnm "$@"
+
+ On MacOS X with fink, I use this:
+
+export DYLD_LIBRARY_PATH=/sw/lib
+exec /sw/bin/pngtopnm "$@"
+
+ On MacOS X with macports, you should use this:
+
+export DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib
+exec /opt/local/bin/pngtopnm "$@"
+
+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
+correctly.
+
+ The test suite can be executed with:
+
+make test
+
+ If the test suite completes successfully, the LilyPond binary has
+been verified.
+
+ More information on the regression test suite is found at *note
+(lilypond-contributor)Regression tests::.
+
+1.7 Problems