Next: The Store, Previous: Defining Packages, Up: Programming Interface [Contents][Index]
Each package definition specifies a build system and arguments for
that build system (see Defining Packages). This build-system
field represents the build procedure of the package, as well implicit
dependencies of that build procedure.
Build systems are <build-system>
objects. The interface to
create and manipulate them is provided by the (guix build-system)
module, and actual build systems are exported by specific modules.
Under the hood, build systems first compile package objects to bags. A bag is like a package, but with less ornamentation—in other words, a bag is a lower-level representation of a package, which includes all the inputs of that package, including some that were implicitly added by the build system. This intermediate representation is then compiled to a derivation (see Derivations).
Build systems accept an optional list of arguments. In package
definitions, these are passed via the arguments
field
(see Defining Packages). They are typically keyword arguments
(see keyword arguments in Guile in GNU
Guile Reference Manual). The value of these arguments is usually
evaluated in the build stratum—i.e., by a Guile process launched
by the daemon (see Derivations).
The main build system is gnu-build-system, which implements the
standard build procedure for GNU packages and many other packages. It
is provided by the (guix build-system gnu)
module.
gnu-build-system represents the GNU Build System, and variants thereof (see configuration and makefile conventions in GNU Coding Standards).
In a nutshell, packages using it configured, built, and installed with
the usual ./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 phases,
notably6:
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.
patch-source-shebangs
Patch shebangs encountered in source files so they refer to the right
store file names. For instance, this changes #!/bin/sh
to
#!/gnu/store/…-bash-4.3/bin/sh
.
configure
Run the configure script with a number of default options, such
as --prefix=/gnu/store/…
, as well as the options specified
by the #:configure-flags
argument.
build
Run make
with the list of flags specified with
#:make-flags
. If the #:parallel-builds?
argument is true
(the default), build with make -j
.
check
Run make check
, or some other target specified with
#:test-target
, unless #:tests? #f
is passed. If the
#:parallel-tests?
argument is true (the default), run make
check -j
.
install
Run make install
with the flags listed in #:make-flags
.
patch-shebangs
Patch shebangs on the installed executable files.
strip
Strip debugging symbols from ELF files (unless #:strip-binaries?
is false), copying them to the debug
output when available
(see Installing Debugging Files).
The build-side module (guix build gnu-build-system)
defines
%standard-phases as the default list of build phases.
%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
#:phases
parameter. For instance, passing:
#:phases (alist-delete 'configure %standard-phases)
means that all the phases described above will be used, except the
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 (guix
build-system gnu)
module for a complete list.) We call these the
implicit inputs of a package, because package definitions don’t
have to mention them.
Other <build-system>
objects are defined to support other
conventions and tools used by free software packages. They inherit most
of 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.
This variable is exported by (guix build-system cmake)
. It
implements the build procedure for packages using the
CMake build tool.
It automatically adds the cmake
package to the set of inputs.
Which package is used can be specified with the #:cmake
parameter.
The #:configure-flags
parameter is taken as a list of flags
passed to the cmake
command. The #:build-type
parameter specifies in abstract terms the flags passed to the compiler;
it defaults to "RelWithDebInfo"
(short for “release mode with
debugging information”), which roughly means that code is compiled with
-O2 -g
, as is the case for Autoconf-based packages by default.
This variable is exported by (guix build-system glib-or-gtk)
. It
is intended for use with packages making use of GLib or GTK+.
This build system adds the following two phases to the ones defined by gnu-build-system:
glib-or-gtk-wrap
The phase glib-or-gtk-wrap
ensures that programs found under
bin/ are able to find GLib’s “schemas” and
GTK+
modules. This is achieved by wrapping the programs in launch scripts
that appropriately set the XDG_DATA_DIRS
and GTK_PATH
environment variables.
It is possible to exclude specific package outputs from that wrapping
process by listing their names in the
#:glib-or-gtk-wrap-excluded-outputs
parameter. This is useful
when an output is known not to contain any GLib or GTK+ binaries, and
where wrapping would gratuitously add a dependency of that output on
GLib and GTK+.
glib-or-gtk-compile-schemas
The phase glib-or-gtk-compile-schemas
makes sure that all GLib’s
GSettings schemas are compiled. Compilation is performed by the
glib-compile-schemas
program. It is provided by the package
glib:bin
which is automatically imported by the build system.
The glib
package providing glib-compile-schemas
can be
specified with the #:glib
parameter.
Both phases are executed after the install
phase.
This variable is exported by (guix build-system python)
. It
implements the more or less standard build procedure used by Python
packages, which consists in running python setup.py build
and
then python setup.py install --prefix=/gnu/store/…
.
For packages that install stand-alone Python programs under bin/
,
it takes care of wrapping these programs so their PYTHONPATH
environment variable points to all the Python libraries they depend on.
Which Python package is used can be specified with the #:python
parameter.
This variable is exported by (guix build-system perl)
. It
implements the standard build procedure for Perl packages, which either
consists in running perl Build.PL --prefix=/gnu/store/…
,
followed by Build
and Build install
; or in running
perl Makefile.PL PREFIX=/gnu/store/…
, followed by
make
and make install
; depending on which of
Build.PL
or Makefile.PL
is present in the package
distribution. Preference is given to the former if both Build.PL
and Makefile.PL
exist in the package distribution. This
preference can be reversed by specifying #t
for the
#:make-maker?
parameter.
The initial perl Makefile.PL
or perl Build.PL
invocation
passes flags specified by the #:make-maker-flags
or
#:module-build-flags
parameter, respectively.
Which Perl package is used can be specified with #:perl
.
This variable is exported by (guix build-system r)
. It
implements the build procedure used by R
packages, which essentially is little more than running R CMD
INSTALL --library=/gnu/store/…
in an environment where
R_LIBS_SITE
contains the paths to all R package inputs. Tests
are run after installation using the R function
tools::testInstalledPackage
.
This variable is exported by (guix build-system ruby)
. It
implements the RubyGems build procedure used by Ruby packages, which
involves running gem build
followed by gem install
.
The source
field of a package that uses this build system
typically references a gem archive, since this is the format that Ruby
developers use when releasing their software. The build system unpacks
the gem archive, potentially patches the source, runs the test suite,
repackages the gem, and installs it. Additionally, directories and
tarballs may be referenced to allow building unreleased gems from Git or
a traditional source release tarball.
Which Ruby package is used can be specified with the #:ruby
parameter. A list of additional flags to be passed to the gem
command can be specified with the #:gem-flags
parameter.
This variable is exported by (guix build-system waf)
. It
implements a build procedure around the waf
script. The common
phases—configure
, build
, and install
—are
implemented by passing their names as arguments to the waf
script.
The waf
script is executed by the Python interpreter. Which
Python package is used to run the script can be specified with the
#:python
parameter.
This variable is exported by (guix build-system haskell)
. It
implements the Cabal build procedure used by Haskell packages, which
involves running runhaskell Setup.hs configure
--prefix=/gnu/store/…
and runhaskell Setup.hs build
.
Instead of installing the package by running runhaskell Setup.hs
install
, to avoid trying to register libraries in the read-only
compiler store directory, the build system uses runhaskell
Setup.hs copy
, followed by runhaskell Setup.hs register
. In
addition, the build system generates the package documentation by
running runhaskell Setup.hs haddock
, unless #:haddock? #f
is passed. Optional Haddock parameters can be passed with the help of
the #:haddock-flags
parameter. If the file Setup.hs
is
not found, the build system looks for Setup.lhs
instead.
Which Haskell compiler is used can be specified with the #:haskell
parameter which defaults to ghc
.
This variable is exported by (guix build-system emacs)
. It
implements an installation procedure similar to the one of Emacs’ own
packaging system (see Packages in The GNU Emacs Manual).
It first creates the package-autoloads.el
file, then it
byte compiles all Emacs Lisp files. Differently from the Emacs
packaging system, the Info documentation files are moved to the standard
documentation directory and the dir file is deleted. Each
package is installed in its own directory under
share/emacs/site-lisp/guix.d.
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.
This variable is exported by (guix build-system trivial)
.
This build system requires a #:builder
argument. This argument
must be a Scheme expression that builds the package’s output(s)—as
with build-expression->derivation
(see build-expression->derivation
).
Please see the (guix build gnu-build-system)
modules for more details about the build phases.
Next: The Store, Previous: Defining Packages, Up: Programming Interface [Contents][Index]