Next: Invoking guix edit, Up: Utilities [Contents][Index]
guix build
The 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
or
coreutils-8.20
, or a derivation such as
/gnu/store/…-coreutils-8.19.drv. In the former case, a
package with the corresponding name (and optionally version) is searched
for among the GNU distribution modules (see Package Modules).
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:
--file=file
-f file
Build the package or derivation that the code within file evaluates to.
As an example, file might contain a package definition like this (see Defining Packages):
(use-modules (guix) (guix build-system gnu) (guix licenses)) (package (name "hello") (version "2.10") (source (origin (method url-fetch) (uri (string-append "mirror://gnu/hello/hello-" version ".tar.gz")) (sha256 (base32 "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i")))) (build-system gnu-build-system) (synopsis "Hello, GNU world: An example GNU package") (description "Guess what GNU Hello prints!") (home-page "http://www.gnu.org/software/hello/") (license gpl3+))
--expression=expr
-e expr
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 be a G-expression, in which case it is used
as a build program passed to gexp->derivation
(see G-Expressions).
Lastly, 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 run-with-store
.
--source
-S
Build the packages’ source derivations, rather than the packages themselves.
For instance, guix build -S gcc
returns something like
/gnu/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).
--sources
Fetch and return the source of package-or-derivation and all their
dependencies, recursively. This is a handy way to obtain a local copy
of all the source code needed to build packages, allowing you to
eventually build them even without network access. It is an extension
of the --source
option and can accept one of the following
optional argument values:
package
This value causes the --sources
option to behave in the same way
as the --source
option.
all
Build all packages’ source derivations, including any source that might
be listed as inputs
. This is the default value.
$ guix build --sources tzdata The following derivations will be built: /gnu/store/…-tzdata2015b.tar.gz.drv /gnu/store/…-tzcode2015b.tar.gz.drv
transitive
Build all packages’ source derivations, as well as all source derivations for packages’ transitive inputs. This can be used e.g. to prefetch package source for later offline building.
$ guix build --sources=transitive tzdata The following derivations will be built: /gnu/store/…-tzcode2015b.tar.gz.drv /gnu/store/…-findutils-4.4.2.tar.xz.drv /gnu/store/…-grep-2.21.tar.xz.drv /gnu/store/…-coreutils-8.23.tar.xz.drv /gnu/store/…-make-4.1.tar.xz.drv /gnu/store/…-bash-4.3.tar.xz.drv …
--system=system
-s system
Attempt to build for system—e.g., i686-linux
—instead of
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.
--target=triplet
Cross-build for triplet, which must be a valid GNU triplet, such
as "mips64el-linux-gnu"
(see GNU
configuration triplets in GNU Configure and Build System).
--with-source=source
Use source as the source of the corresponding package.
source must be a file name or a URL, as for guix
download
(see Invoking guix download).
The “corresponding package” is taken to be one specified on the
command line whose name matches the base of source—e.g., if
source is /src/guile-2.0.10.tar.gz
, the corresponding
package is guile
. Likewise, the version string is inferred from
source; in the previous example, it’s 2.0.10
.
This option allows users to try out versions of packages other than the
one provided by the distribution. The example below downloads
ed-1.7.tar.gz from a GNU mirror and uses that as the source for
the ed
package:
guix build ed --with-source=mirror://gnu/ed/ed-1.7.tar.gz
As a developer, --with-source
makes it easy to test release
candidates:
guix build guile --with-source=../guile-2.0.9.219-e1bb7.tar.xz
… or to build from a checkout in a pristine environment:
$ git clone git://git.sv.gnu.org/guix.git $ guix build guix --with-source=./guix
--no-grafts
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.
--derivations
-d
Return the derivation paths, not the output paths, of the given packages.
--root=file
-r file
Make file a symlink to the result, and register it as a garbage collector root.
--log-file
Return the build log file names or URLs 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)'
If a log is unavailable locally, and unless --no-substitutes
is
passed, the command looks for a corresponding log on one of the
substitute servers (as specified with --substitute-urls
.)
So for instance, let’s say you want to see the build log of GDB on MIPS
but you’re actually on an x86_64
machine:
$ guix build --log-file gdb -s mips64el-linux http://hydra.gnu.org/log/…-gdb-7.10
You can freely access a huge library of build logs!
In addition, 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
following:
--load-path=directory
-L directory
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-failed
-K
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.
--dry-run
-n
Do not build the derivations.
--fallback
When substituting a pre-built binary fails, fall back to building packages locally.
--substitute-urls=urls
Consider urls the whitespace-separated list of substitute source
URLs, overriding the default list of URLs of guix-daemon
(see guix-daemon
URLs).
This means that substitutes may be downloaded from urls, provided they are signed by a key authorized by the system administrator (see Substitutes).
--no-substitutes
Do not use substitutes for build products. That is, always build things locally instead of allowing downloads of pre-built binaries (see Substitutes).
--no-build-hook
Do not attempt to offload builds via the daemon’s “build hook” (see Daemon Offload Setup). That is, always build things locally instead of offloading builds to remote machines.
--max-silent-time=seconds
When the build or substitution process remains silent for more than seconds, terminate it and report a build failure.
--timeout=seconds
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
--timeout=0
.
--verbosity=level
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.
--cores=n
-c n
Allow the use of up to n CPU cores for the build. The special
value 0
means to use as many CPU cores as available.
--max-jobs=n
-M n
Allow at most n build jobs in parallel. See --max-jobs
, for details about this option and the
equivalent guix-daemon
option.
Behind the scenes, guix build
is essentially an interface to
the package-derivation
procedure of the (guix packages)
module, and to the build-derivations
procedure of the (guix
derivations)
module.
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
below:
$ 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.
Next: Invoking guix edit, Up: Utilities [Contents][Index]