guix build command builds packages or derivations and
their dependencies, and prints the resulting store paths. Note that it
does not modify the user’s profile—this is the job of the
guix package command (see Invoking guix package). Thus,
it is mainly useful for distribution developers.
The general syntax is:
guix build options package-or-derivation…
package-or-derivation may be either the name of a package found in
the software distribution such as
coreutils-8.20, or a derivation such as
/nix/store/…-coreutils-8.19.drv. Alternatively, the
--expression option may be used to specify a Scheme expression
that evaluates to a package; this is useful when disambiguation among
several same-named packages or package variants is needed.
The options may be zero or more of the following:
Build the package or derivation expr evaluates to.
For example, expr may be
(@ (gnu packages guile)
guile-1.8), which unambiguously designates this specific variant of
version 1.8 of Guile.
Alternately, expr may refer to a zero-argument monadic procedure
(see The Store Monad). The procedure must return a derivation as a
monadic value, which is then passed through
Build the packages’ source derivations, rather than the packages themselves.
guix build -S gcc returns something like
/nix/store/…-gcc-4.7.2.tar.bz2, which is GCC’s source tarball.
The returned source tarball is the result of applying any patches and
code snippets specified in the package’s
origin (see Defining Packages).
Attempt to build for system—e.g.,
the host’s system type.
An example use of this is on Linux-based systems, which can emulate
different personalities. For instance, passing
--system=i686-linux on an
x86_64-linux system allows users
to build packages in a complete 32-bit environment.
Cross-build for triplet, which must be a valid GNU triplet, such
"mips64el-linux-gnu" (see GNU
configuration triplets in GNU Configure and Build System).
Return the derivation paths, not the output paths, of the given packages.
Keep the build tree of failed builds. Thus, if a build fail, its build tree is kept under /tmp, in a directory whose name is shown at the end of the build log. This is useful when debugging build issues.
Do not build the derivations.
When substituting a pre-built binary fails, fall back to building packages locally.
Do not use substitutes for build products. That is, always build things locally instead of allowing downloads of pre-built binaries.
When the build or substitution process remains silent for more than seconds, terminate it and report a build failure.
Allow the use of up to n CPU cores for the build. The special
0 means to use as many CPU cores as available.
Make file a symlink to the result, and register it as a garbage collector root.
Use the given verbosity level. level must be an integer between 0 and 5; higher means more verbose output. Setting a level of 4 or more may be helpful when debugging setup issues with the build daemon.
Return the build log file names for the given package-or-derivations, or raise an error if build logs are missing.
This works regardless of how packages or derivations are specified. For instance, the following invocations are equivalent:
guix build --log-file `guix build -d guile` guix build --log-file `guix build guile` guix build --log-file guile guix build --log-file -e '(@ (gnu packages guile) guile-2.0)'
Behind the scenes,
guix build is essentially an interface to
package-derivation procedure of the
module, and to the
build-derivations procedure of the