]> git.donarmstrong.com Git - lilypond.git/blobdiff - Documentation/included/compile.itexi
Imported Upstream version 2.16.0
[lilypond.git] / Documentation / included / compile.itexi
index 8f9a237608a34cc4ce69cdf9ac747adcc875e55e..eb24c591807cdecbf7ab1df8e0d1a72ce6fa0bb3 100644 (file)
@@ -43,7 +43,7 @@ without compiling}.
 
 Attempts to compile LilyPond natively on Windows have been
 unsuccessful, though a workaround is available (see
-@rcontrib{Lilydev}).
+@rcontrib{LilyDev}).
 
 
 @node Requirements
@@ -396,7 +396,7 @@ directory.  Here are the relevant lines taken from the output of
 By default, `@command{make@tie{}install}' will install all the
 files in @file{/usr/local/bin}, @file{/usr/local/lib} etc.  You
 can specify an installation prefix other than @file{/usr/local}
-using `@code{--prefix}', for instance `@code{--prefix=$HOME}'.
+using `@option{--prefix}', for instance `@option{--prefix=$HOME}'.
 @end quotation
 
 A typical installation prefix is @file{$HOME/usr}:
@@ -458,6 +458,10 @@ make help
 
 TODO: Describe what @command{make} actually does.
 
+@seealso
+@ref{Generating documentation} provides more info on the @command{make} targets
+used to build the LilyPond documentation.
+
 
 @node Saving time with the -j option
 @subsection Saving time with the @option{-j} option
@@ -483,9 +487,9 @@ that case, running @samp{make} without the @option{-j} is advised.
 
 If you want to build multiple versions of LilyPond with different
 configuration settings, you can use the
-@code{--enable-config=@var{CONF}} option of @command{configure}.
-You should use @code{make@tie{}conf=@var{CONF}} to generate the
-output in @file{out-@var{CONF}}.  For example, suppose you want to
+@option{--enable-config=@var{conf}} option of @command{configure}.
+You should use @code{make@tie{}conf=@var{conf}} to generate the
+output in @file{out-@var{conf}}.  For example, suppose you want to
 build with and without profiling, then use the following for the
 normal build
 
@@ -576,6 +580,7 @@ re-install.  See @ref{Configuring target directories}.
 @menu
 * Documentation editor's edit/compile cycle::
 * Building documentation::
+* Building a single document::
 * Saving time with CPU_COUNT::
 * AJAX search::
 * Installing documentation::
@@ -592,7 +597,8 @@ Initial documentation build:
 
 @example
 make [-j@var{X}]
-make [-j@var{X} CPU_COUNT=@var{X}] doc  @emph{## can take an hour or more}
+make [-j@var{X} CPU_COUNT=@var{X}] doc          @emph{## can take an hour or more}
+make [-j@var{X} CPU_COUNT=@var{X}] doc-stage-1  @emph{## to build only PDF documentation}
 @end example
 
 @item
@@ -604,16 +610,17 @@ Edit/compile cycle:
 make [-j@var{X}]                  @emph{## needed if editing outside}
                             @emph{##   Documentation/, but useful anyway}
                             @emph{##   for finding Texinfo errors.}
-touch Documentation/*te??   @emph{## bug workaround}
 make [-j@var{X} CPU_COUNT=@var{X}] doc  @emph{## usually faster than initial build.}
 @end example
 
 @item
 Reset:
 
-In some cases, it is possible to clean the compiled documentation
-with @samp{make@tie{}doc-clean}, but this method is not guaranteed
-to fix everything.  Instead, we recommend that you delete your
+It is generally possible to remove the compiled documentation from
+your system
+with @samp{make@tie{}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
 @file{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
@@ -631,11 +638,20 @@ documentation can be built by issuing:
 make doc
 @end example
 
-The first time you run @command{make@tie{}doc}, the process can
-easily take an hour or more.  After that, @command{make@tie{}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,
+
+@example
+make doc-stage-1
+@end example
+
+@warning{The first time you run @command{make@tie{}doc}, the
+process can easily take an hour or more with not much output
+on the command line.}
+
+After this initial build, @command{make@tie{}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 @command{make@tie{}doc} succeeds, the HTML documentation tree
 is available in @file{out-www/offline-root/}, and can be browsed
@@ -646,56 +662,70 @@ the docs.  Please do not complain about anything which is broken
 in those places; the only complete set of documentation is in
 @file{out-www/offline-root/} from the top of the source tree.
 
-Compilation of documentation in Info format with images can be
-done separately by issuing:
+@command{make@tie{}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 @command{make@tie{}doc-clean}.  To
+remove all the logfiles generated by the compilation process, use:
 
 @example
-make info
+make log-clean
 @end example
 
-@knownissues
+@code{make@tie{}doc} compiles the documents for all languages.  To
+save some compile time, the English language documents can be
+compiled on their own with:
+
+@example
+make LANGS='' doc
+@end example
 
-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 @code{make@tie{}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 @command{touch} the top source file for any
-manual you've edited.  For example, if you make changes to a file
-in @file{notation/}, do:
+@noindent 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:
 
 @example
-touch Documentation/notation.tely
+make LANGS='de fr' doc
 @end example
 
-@noindent
-The top sources possibly affected by this are:
+@noindent Note that this will also compile the English version.
+
+Compilation of documentation in Info format with images can be
+done separately by issuing:
 
 @example
-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
+make info
 @end example
 
 @noindent
-You can @command{touch} all of them at once with:
+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:
 
 @example
-touch Documentation/*te??
+No rule to make target `X', needed by `Y'
 @end example
 
 @noindent
-However, this will rebuild all of the manuals
-indiscriminately---it is more efficient to @command{touch} only
-the affected files.
+Your best bet is to delete the file Y.dep and to try again.
+
+@node Building a single document
+@unnumberedsubsubsec Building a single document
+It's possible to build a single document.  For example, to rebuild
+only @file{contributor.pdf}, do the following:
+
+@example
+cd build/
+cd Documentation/
+touch ../../Documentation/contributor.texi
+make out=www out-www/contributor.pdf
+@end example
 
+If you are only working on a single document, test-building it in
+this way can give substantial time savings - recreating
+@file{contributor.pdf}, for example, takes a matter of seconds.
 
 @node Saving time with CPU_COUNT
 @unnumberedsubsubsec Saving time with @code{CPU_COUNT}