Next: Defining Package Variants, Previous: Módulos de pacote, Up: Interface de programação [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 (list gawk)) (synopsis "Hello, GNU world: An example GNU package") (description "Guess what GNU Hello prints!") (home-page "https://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 the 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 in 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 Módulos de pacote).
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 Invocando guix download
) and guix hash
(see Invocando 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 Sistemas de compilação). 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.
When you start packaging non-trivial software, you may need tools to manipulate those build phases, manipulate files, and so on. See Build Utilities, for more on this.
arguments
field specifies options for the build system
(see Sistemas de compilação). Here it is interpreted by gnu-build-system
as a request run configure with the --enable-silent-rules
flag.
What about these quote ('
) characters? They are Scheme syntax to
introduce a literal list; '
is synonymous with quote
.
Sometimes you’ll also see `
(a backquote, synonymous with
quasiquote
) and ,
(a comma, synonymous with unquote
).
See quoting in GNU Guile Reference Manual, for
details. Here the value of the arguments
field is a list of
arguments passed to the build system down the road, as with apply
(see apply
in GNU Guile Reference Manual).
The hash-colon (#:
) sequence defines a Scheme keyword
(see Keywords in GNU Guile Reference Manual), and
#:configure-flags
is a keyword used to pass a keyword argument to the
build system (see Coding With Keywords in GNU Guile Reference
Manual).
inputs
field specifies inputs to the build process—i.e.,
build-time or run-time dependencies of the package. Here, we add an input,
a reference to 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 Sistemas de compilação).
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.
Going further: Intimidated by the Scheme language or curious about it? The Cookbook has a short section to get started that recaps some of the things shown above and explains the fundamentals. See A Scheme Crash Course in GNU Guix Cookbook, for more information.
Once a package definition is in place, the package may actually be built
using the guix build
command-line tool (see Invocando guix build
),
troubleshooting any build failures you encounter (see Depurando falhas de compilação). You can easily jump back to the package definition using the
guix edit
command (see Invocando guix edit
). See Diretrizes de empacotamento, for more information on how to test package definitions, and
Invocando guix lint
, for information on how to check a definition for
style conformance.
Lastly, see Canais, for information on how to extend the distribution
by adding your own package definitions in a “channel”.
Finally, updating the package definition to a new upstream version can be
partly automated by the guix refresh
command (see Invocando 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 O armazém).
Return the <derivation>
object of package for system
(see Derivações).
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 O armazém).
Similarly, it is possible to compute a derivation that cross-builds a package for some other system:
<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 "aarch64-linux-gnu"
(see Specifying
Target Triplets in Autoconf).
Once you have package definitions, you can easily define variants of those packages. See Defining Package Variants, for more on that.
Next: Defining Package Variants, Previous: Módulos de pacote, Up: Interface de programação [Contents][Index]