A number of options that control the build process are common to
guix build and other commands that can spawn builds, such as
guix package or
guix archive. These are the
Add directory to the front of the package module search path (see Package Modules).
This allows users to define their own packages and make them visible to the command-line tools.
Keep the build tree of failed builds. Thus, if a build fails, 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. See Debugging Build Failures, for tips and tricks on how to debug build issues.
Keep going when some of the derivations fail to build; return only once all the builds have either completed or failed.
The default behavior is to stop as soon as one of the specified derivations has failed.
Do not build the derivations.
When substituting a pre-built binary fails, fall back to building packages locally.
Consider urls the whitespace-separated list of substitute source
URLs, overriding the default list of URLs of
This means that substitutes may be downloaded from urls, provided they are signed by a key authorized by the system administrator (see Substitutes).
When urls is the empty string, substitutes are effectively disabled.
Do not use substitutes for build products. That is, always build things locally instead of allowing downloads of pre-built binaries (see Substitutes).
Do not “graft” packages. In practice, this means that package updates available as grafts are not applied. See Security Updates, for more information on grafts.
Build each derivation n times in a row, and raise an error if consecutive build results are not bit-for-bit identical.
This is a useful way to detect non-deterministic builds processes. Non-deterministic build processes are a problem because they make it practically impossible for users to verify whether third-party binaries are genuine. See Invoking guix challenge, for more.
Note that, currently, the differing build results are not kept around,
so you will have to manually investigate in case of an error—e.g., by
stashing one of the build results with
guix archive --export
(see Invoking guix archive), then rebuilding, and finally comparing
the two results.
Do not attempt to offload builds via the “build hook” of the daemon (see Daemon Offload Setup). That is, always build things locally instead of offloading builds to remote machines.
When the build or substitution process remains silent for more than seconds, terminate it and report a build failure.
Likewise, when the build or substitution process lasts for more than seconds, terminate it and report a build failure.
By default there is no timeout. This behavior can be restored with
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.
Allow the use of up to n CPU cores for the build. The special
0 means to use as many CPU cores as available.
Allow at most n build jobs in parallel. See
--max-jobs, for details about this option and the
Behind the scenes,
guix build is essentially an interface to
package-derivation procedure of the
module, and to the
build-derivations procedure of the
In addition to options explicitly passed on the command line,
guix build and other
guix commands that support
building honor the
GUIX_BUILD_OPTIONS environment variable.
Users can define this variable to a list of command line options that
will automatically be used by
guix build and other
guix commands that can perform builds, as in the example
$ export GUIX_BUILD_OPTIONS="--no-substitutes -c 2 -L /foo/bar"
These options are parsed independently, and the result is appended to the parsed command-line options.