Next: Build Systems, Up: Programming Interface [Contents][Index]
The high-level interface to package definitions is implemented in the
(guix packages)
and (guix build-system)
modules. As an
example, the package definition, or recipe, for the GNU Hello
package looks like this:
(define-module (gnu packages hello) #:use-module (guix packages) #:use-module (guix download) #:use-module (guix build-system gnu) #:use-module (guix licenses) #:use-module (gnu packages gawk)) (define-public hello (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) (arguments `(#:configure-flags '("--enable-silent-rules"))) (inputs `(("gawk" ,gawk))) (synopsis "Hello, GNU world: An example GNU package") (description "Guess what GNU Hello prints!") (home-page "http://www.gnu.org/software/hello/") (license gpl3+)))
Without being a Scheme expert, the reader may have guessed the meaning
of the various fields here. This expression binds variable hello
to a <package>
object, which is essentially a record
(see Scheme records in GNU Guile Reference Manual).
This package object can be inspected using procedures found in the
(guix packages)
module; for instance, (package-name hello)
returns—surprise!—"hello"
.
With luck, you may be able to import part or all of the definition of
the package you are interested in from another repository, using the
guix import
command (see Invoking guix import).
In the example above, hello is defined into a module of its own,
(gnu packages hello)
. Technically, this is not strictly
necessary, but it is convenient to do so: all the packages defined in
modules under (gnu packages …)
are automatically known to
the command-line tools (see Package Modules).
There are a few points worth noting in the above package definition:
source
field of the package is an <origin>
object
(see origin Reference, for the complete reference).
Here, the url-fetch
method from (guix download)
is used,
meaning that the source is a file to be downloaded over FTP or HTTP.
The mirror://gnu
prefix instructs url-fetch
to use one of
the GNU mirrors defined in (guix download)
.
The sha256
field specifies the expected SHA256 hash of the file
being downloaded. It is mandatory, and allows Guix to check the
integrity of the file. The (base32 …)
form introduces the
base32 representation of the hash. You can obtain this information with
guix download
(see Invoking guix download) and guix
hash
(see Invoking guix hash).
When needed, the origin
form can also have a patches
field
listing patches to be applied, and a snippet
field giving a
Scheme expression to modify the source code.
build-system
field specifies the procedure to build the
package (see Build Systems). Here, gnu-build-system
represents the familiar GNU Build System, where packages may be
configured, built, and installed with the usual ./configure &&
make && make check && make install
command sequence.
arguments
field specifies options for the build system
(see Build Systems). Here it is interpreted by
gnu-build-system as a request run configure with the
--enable-silent-rules
flag.
inputs
field specifies inputs to the build process—i.e.,
build-time or run-time dependencies of the package. Here, we define an
input called "gawk"
whose value is that of the gawk
variable; gawk is itself bound to a <package>
object.
Note that GCC, Coreutils, Bash, and other essential tools do not need to be specified as inputs here. Instead, gnu-build-system takes care of ensuring that they are present (see Build Systems).
However, any other dependencies need to be specified in the
inputs
field. Any dependency not specified here will simply be
unavailable to the build process, possibly leading to a build failure.
See package Reference, for a full description of possible fields.
Once a package definition is in place, the
package may actually be built using the guix build
command-line
tool (see Invoking guix build). You can easily jump back to the
package definition using the guix edit
command
(see Invoking guix edit).
See Packaging Guidelines, for
more information on how to test package definitions, and
Invoking guix lint, for information on how to check a definition
for style conformance.
Eventually, updating the package definition to a new upstream version
can be partly automated by the guix refresh
command
(see Invoking guix refresh).
Behind the scenes, a derivation corresponding to the <package>
object is first computed by the package-derivation
procedure.
That derivation is stored in a .drv
file under /gnu/store.
The build actions it prescribes may then be realized by using the
build-derivations
procedure (see The Store).
Return the <derivation>
object of package for system
(see Derivations).
package must be a valid <package>
object, and system
must be a string denoting the target system type—e.g.,
"x86_64-linux"
for an x86_64 Linux-based GNU system. store
must be a connection to the daemon, which operates on the store
(see The Store).
Similarly, it is possible to compute a derivation that cross-builds a package for some other system:
Return the <derivation>
object of package cross-built from
system to target.
target must be a valid GNU triplet denoting the target hardware
and operating system, such as "mips64el-linux-gnu"
(see GNU configuration triplets in GNU
Configure and Build System).
• package Reference : | The package data type. | |
• origin Reference: | The origin data type. |
Next: Build Systems, Up: Programming Interface [Contents][Index]