doc: Add "Build Systems" section.

* doc/guix.texi (Defining Packages): Add 'arguments' field in the
  example; update 'synopsis' and 'description'.  Remove most of the
  description of 'build-system', and instead reference to the "Build
  Systems" node.  Briefly describe 'arguments' field, and remove more
  elaborate description.  Add cross-reference to "Packaging Guidelines".
  (Build Systems): New node.
  (Packaging Guidelines): Mention '--log-file'.

doc/guix.texi

@@ -1301,6 +1301,7 @@ package definitions.
 
 @menu
 * Defining Packages::           Defining new packages.
+* Build Systems::               Specifying how packages are built.
 * The Store::                   Manipulating the package store.
 * Derivations::                 Low-level interface to package derivations.
 * The Store Monad::             Purely functional interface to the store.
@@ -1332,9 +1333,10 @@ package looks like this:
              (sha256
               (base32 "0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6"))))
     (build-system gnu-build-system)
+    (arguments `(#:configure-flags '("--enable-silent-rules")))
     (inputs `(("gawk" ,gawk)))
-    (synopsis "GNU Hello")
+    (synopsis "Hello, GNU world: An example GNU package")
-    (description "Yeah...")
+    (description "Guess what GNU Hello prints!")
     (home-page "http://www.gnu.org/software/hello/")
     (license gpl3+)))
 @end example
@@ -1379,22 +1381,17 @@ Scheme expression to modify the source code.
 
 @item
 @cindex GNU Build System
-The @code{build-system} field is set to @var{gnu-build-system}.  The
+The @code{build-system} field specifies the procedure to build the
-@var{gnu-build-system} variable is defined in the @code{(guix
+package (@pxref{Build Systems}).  Here, @var{gnu-build-system}
-build-system gnu)} module, and is bound to a @code{<build-system>}
+represents the familiar GNU Build System, where packages may be
-object.
+configured, built, and installed with the usual @code{./configure &&
+make && make check && make install} command sequence.
 
-Naturally, @var{gnu-build-system} represents the familiar GNU Build
+@item
-System, and variants thereof (@pxref{Configuration, configuration and
+The @code{arguments} field specifies options for the build system
-makefile conventions,, standards, GNU Coding Standards}).  In a
+(@pxref{Build Systems}).  Here it is interpreted by
-nutshell, packages using the GNU Build System may be configured, built,
+@var{gnu-build-system} as a request run @file{configure} with the
-and installed with the usual @code{./configure && make && make check &&
+@code{--enable-silent-rules} flag.
-make install} command sequence.  This is what @var{gnu-build-system}
-does.
-
-In addition, @var{gnu-build-system} ensures that the ``standard''
-environment for GNU packages is available.  This includes tools such as
-GCC, Coreutils, Bash, Make, Diffutils, and Patch.
 
 @item
 The @code{inputs} field specifies inputs to the build process---i.e.,
@@ -1404,40 +1401,23 @@ variable; @var{gawk} is itself bound to a @code{<package>} object.
 
 Note that GCC, Coreutils, Bash, and other essential tools do not need to
 be specified as inputs here.  Instead, @var{gnu-build-system} takes care
-of ensuring that they are present.
+of ensuring that they are present (@pxref{Build Systems}).
 
 However, any other dependencies need to be specified in the
 @code{inputs} field.  Any dependency not specified here will simply be
 unavailable to the build process, possibly leading to a build failure.
 @end itemize
 
-There are other fields that package definitions may provide.  Of
-particular interest is the @code{arguments} field.  When specified, it
-must be bound to a list of additional arguments to be passed to the
-build system.  For instance, the above definition could be augmented
-with the following field initializer:
-
-@example
-    (arguments `(#:tests? #f
-                 #:configure-flags '("--enable-silent-rules")))
-@end example
-
-@noindent
-These are keyword arguments (@pxref{Optional Arguments, keyword
-arguments in Guile,, guile, GNU Guile Reference Manual}).  They are
-passed to @var{gnu-build-system}, which interprets them as meaning ``do
-not run @code{make check}'', and ``run @file{configure} with the
-@code{--enable-silent-rules} flag''.  The value of these keyword
-parameters is actually evaluated in the @dfn{build stratum}---i.e., by a
-Guile process launched by the daemon (@pxref{Derivations}).
-
 Once a package definition is in place@footnote{Simple package
 definitions like the one above may be automatically converted from the
 Nixpkgs distribution using the @command{guix import} command.}, the
 package may actually be built using the @code{guix build} command-line
-tool (@pxref{Invoking guix build}).  Eventually, updating the package
+tool (@pxref{Invoking guix build}).  @xref{Packaging Guidelines}, for
-definition to a new upstream version can be partly automated by the
+more information on how to test package definitions.
-@command{guix refresh} command (@pxref{Invoking guix refresh}).
+
+Eventually, updating the package definition to a new upstream version
+can be partly automated by the @command{guix refresh} command
+(@pxref{Invoking guix refresh}).
 
 Behind the scenes, a derivation corresponding to the @code{<package>}
 object is first computed by the @code{package-derivation} procedure.
@@ -1473,6 +1453,164 @@ Configure and Build System}).
 @end deffn
 
 
+@node Build Systems
+@section Build Systems
+
+@cindex build system
+Each package definition specifies a @dfn{build system} and arguments for
+that build system (@pxref{Defining Packages}).  This @code{build-system}
+field represents the build procedure of the package, as well implicit
+dependencies of that build procedure.
+
+Build systems are @code{<build-system>} objects.  The interface to
+create and manipulate them is provided by the @code{(guix build-system)}
+module, and actual build systems are exported by specific modules.
+
+Build systems accept an optional list of @dfn{arguments}.  In package
+definitions, these are passed @i{via} the @code{arguments} field
+(@pxref{Defining Packages}).  They are typically keyword arguments
+(@pxref{Optional Arguments, keyword arguments in Guile,, guile, GNU
+Guile Reference Manual}).  The value of these arguments is usually
+evaluated in the @dfn{build stratum}---i.e., by a Guile process launched
+by the daemon (@pxref{Derivations}).
+
+The main build system is @var{gnu-build-system}, which implements the
+standard build procedure for GNU packages and many other packages.  It
+is provided by the @code{(guix build-system gnu)} module.
+
+@defvr {Scheme Variable} gnu-build-system
+@var{gnu-build-system} represents the GNU Build System, and variants
+thereof (@pxref{Configuration, configuration and makefile conventions,,
+standards, GNU Coding Standards}).
+
+@cindex build phases
+In a nutshell, packages using it configured, built, and installed with
+the usual @code{./configure && make && make check && make install}
+command sequence.  In practice, a few additional steps are often needed.
+All these steps are split up in separate @dfn{phases},
+notably@footnote{Please see the @code{(guix build gnu-build-system)}
+modules for more details about the build phases.}:
+
+@table @code
+@item unpack
+Unpack the source tarball, and change the current directory to the
+extracted source tree.  If the source is actually a directory, copy it
+to the build tree, and enter that directory.
+
+@item patch-source-shebangs
+Patch shebangs encountered in source files so they refer to the right
+store file names.  For instance, this changes @code{#!/bin/sh} to
+@code{#!/gnu/store/@dots{}-bash-4.3/bin/sh}.
+
+@item configure
+Run the @file{configure} script with a number of default options, such
+as @code{--prefix=/gnu/store/@dots{}}, as well as the options specified
+by the @code{#:configure-flags} argument.
+
+@item build
+Run @code{make} with the list of flags specified with
+@code{#:make-flags}.  If the @code{#:parallel-builds?} argument is true
+(the default), build with @code{make -j}.
+
+@item check
+Run @code{make check}, or some other target specified with
+@code{#:test-target}, unless @code{#:tests? #f} is passed.  If the
+@code{#:parallel-tests?} argument is true (the default), run @code{make
+check -j}.
+
+@item install
+Run @code{make install} with the flags listed in @code{#:make-flags}.
+
+@item patch-shebangs
+Patch shebangs on the installed executable files.
+
+@item strip
+Strip debugging symbols from ELF files (unless @code{#:strip-binaries?}
+is false), copying them to the @code{debug} output when available
+(@pxref{Installing Debugging Files}).
+@end table
+
+@vindex %standard-phases
+The build-side module @code{(guix build gnu-build-system)} defines
+@var{%standard-phases} as the default list of build phases.
+@var{%standard-phases} is a list of symbol/procedure pairs, where the
+procedure implements the actual phase.
+
+The list of phases used for a particular package can be changed with the
+@code{#:phases} parameter.  For instance, passing:
+
+@example
+#:phases (alist-delete 'configure %standard-phases)
+@end example
+
+means that all the phases described above will be used, expect the
+@code{configure} phase.
+
+In addition, this build system ensures that the ``standard'' environment
+for GNU packages is available.  This includes tools such as GCC, libc,
+Coreutils, Bash, Make, Diffutils, grep, and sed (see the @code{(guix
+build-system gnu)} module for a complete list.)  We call these the
+@dfn{implicit inputs} of a package, because package definitions don't
+have to mention them.
+@end defvr
+
+Other @code{<build-system>} objects are defined to support other
+conventions and tools used by free software packages.  They inherit most
+of @var{gnu-build-system}, and differ mainly in the set of inputs
+implicitly added to the build process, and in the list of phases
+executed.  Some of these build systems are listed below.
+
+@defvr {Scheme Variable} cmake-build-system
+This variable is exported by @code{(guix build-system cmake)}.  It
+implements the build procedure for packages using the
+@url{http://www.cmake.org, CMake build tool}.
+
+It automatically adds the @code{cmake} package to the set of inputs.
+Which package is used can be specified with the @code{#:cmake}
+parameter.
+@end defvr
+
+@defvr {Scheme Variable} python-build-system
+This variable is exported by @code{(guix build-system python)}.  It
+implements the more or less standard build procedure used by Python
+packages, which consists in running @code{python setup.py build} and
+then @code{python setup.py install --prefix=/gnu/store/@dots{}}.
+
+For packages that install stand-alone Python programs under @code{bin/},
+it takes care of wrapping these programs so their @code{PYTHONPATH}
+environment variable points to all the Python libraries they depend on.
+
+Which Python package is used can be specified with the @code{#:python}
+parameter.
+@end defvr
+
+@defvr {Scheme Variable} perl-build-system
+This variable is exported by @code{(guix build-system perl)}.  It
+implements the standard build procedure for Perl packages, which
+consists in running @code{perl Makefile.PL PREFIX=/gnu/store/@dots{}},
+followed by @code{make} and @code{make install}.
+
+The initial @code{perl Makefile.PL} invocation passes flags specified by
+the @code{#:make-maker-flags} parameter.
+
+Which Perl package is used can be specified with @code{#:perl}.
+@end defvr
+
+
+Lastly, for packages that do not need anything as sophisticated, a
+``trivial'' build system is provided.  It is trivial in the sense that
+it provides basically no support: it does not pull any implicit inputs,
+and does not have a notion of build phases.
+
+@defvr {Scheme Variable} trivial-build-system
+This variable is exported by @code{(guix build-system trivial)}.
+
+This build system requires a @code{#:builder} argument.  This argument
+must be a Scheme expression that builds the package's output(s)---as
+with @code{build-expression->derivation} (@pxref{Derivations,
+@code{build-expression->derivation}}).
+@end defvr
+
 @node The Store
 @section The Store
 
@@ -2398,7 +2536,9 @@ called @code{gnew}, you may run this command from the Guix build tree:
 @end example
 
 Using @code{--keep-failed} makes it easier to debug build failures since
-it provides access to the failed build tree.
+it provides access to the failed build tree.  Another useful
+command-line option when debugging is @code{--log-file}, to access the
+build log.
 
 If the package is unknown to the @command{guix} command, it may be that
 the source file contains a syntax error, or lacks a @code{define-public}