Next: Хранилище, Previous: Описание пакетов, Up: Программный интерфейс [Contents][Index]
Each package definition specifies a build system and arguments for
that build system (see Описание пакетов). This build-system
field represents the build procedure of the package, as well as 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 Деривации).
Build systems accept an optional list of arguments. In package
definitions, these are passed via the arguments field
(see Описание пакетов). 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 Деривации).
The main build system is gnu-build-system, which implements the
standard build procedure for GNU 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 are 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, notably15:
unpackUnpack 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-shebangsPatch 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.
configureRun 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.
buildRun make with the list of flags specified with #:make-flags.
If the #:parallel-build? argument is true (the default), build with
make -j.
checkRun 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.
installRun make install with the flags listed in #:make-flags.
patch-shebangsPatch shebangs on the installed executable files.
stripStrip debugging symbols from ELF files (unless #:strip-binaries? is
false), copying them to the debug output when available
(see Установка файлов отладки).
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 (modify-phases %standard-phases (delete 'configure))
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 do not 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 ant). It implements
the build procedure for Java packages that can be built with
Ant build tool.
It adds both ant and the Java Development Kit (JDK) as provided
by the icedtea package to the set of inputs. Different packages can
be specified with the #:ant and #:jdk parameters,
respectively.
When the original package does not provide a suitable Ant build file, the
parameter #:jar-name can be used to generate a minimal Ant build file
build.xml with tasks to build the specified jar archive. In this
case the parameter #:source-dir can be used to specify the source
sub-directory, defaulting to “src”.
The #:main-class parameter can be used with the minimal ant buildfile
to specify the main class of the resulting jar. This makes the jar file
executable. The #:test-include parameter can be used to specify the
list of junit tests to run. It defaults to (list "**/*Test.java").
The #:test-exclude can be used to disable some tests. It defaults to
(list "**/Abstract*.java"), because abstract classes cannot be run as
tests.
The parameter #:build-target can be used to specify the Ant task that
should be run during the build phase. By default the “jar” task
will be run.
This variable is exported by (guix build-system android-ndk). It
implements a build procedure for Android NDK (native development kit)
packages using a Guix-specific build process.
The build system assumes that packages install their public interface (header) files to the subdirectory "include" of the "out" output and their libraries to the subdirectory "lib" of the "out" output.
It’s also assumed that the union of all the dependencies of a package has no conflicting files.
For the time being, cross-compilation is not supported - so right now the libraries and header files are assumed to be host tools.
These variables, exported by (guix build-system asdf), implement
build procedures for Common Lisp packages using
“ASDF”. ASDF is a system
definition facility for Common Lisp programs and libraries.
The asdf-build-system/source system installs the packages in source
form, and can be loaded using any common lisp implementation, via ASDF. The
others, such as asdf-build-system/sbcl, install binary systems in the
format which a particular implementation understands. These build systems
can also be used to produce executable programs, or lisp images which
contain a set of packages pre-loaded.
The build system uses naming conventions. For binary packages, the package
name should be prefixed with the lisp implementation, such as sbcl-
for asdf-build-system/sbcl.
Additionally, the corresponding source package should be labeled using the
same convention as python packages (see Модули Python), using the
cl- prefix.
For binary packages, each system should be defined as a Guix package. If
one package origin contains several systems, package variants can be
created in order to build all the systems. Source packages, which use
asdf-build-system/source, may contain several systems.
In order to create executable programs and images, the build-side procedures
build-program and build-image can be used. They should be
called in a build phase after the create-symlinks phase, so that the
system which was just built can be used within the resulting image.
build-program requires a list of Common Lisp expressions to be passed
as the #:entry-program argument.
If the system is not defined within its own .asd file of the same
name, then the #:asd-file parameter should be used to specify which
file the system is defined in. Furthermore, if the package defines a system
for its tests in a separate file, it will be loaded before the tests are run
if it is specified by the #:test-asd-file parameter. If it is not
set, the files <system>-tests.asd, <system>-test.asd,
tests.asd, and test.asd will be tried if they exist.
If for some reason the package must be named in a different way than the
naming conventions suggest, the #:asd-system-name parameter can be
used to specify the name of the system.
This variable is exported by (guix build-system cargo). It supports
builds of packages using Cargo, the build tool of the
Rust programming language.
It adds rustc and cargo to the set of inputs. A different
Rust package can be specified with the #:rust parameter.
Regular cargo dependencies should be added to the package definition via the
#:cargo-inputs parameter as a list of name and spec pairs, where the
spec can be a package or a source definition. Note that the spec must
evaluate to a path to a gzipped tarball which includes a Cargo.toml
file at its root, or it will be ignored. Similarly, cargo dev-dependencies
should be added to the package definition via the
#:cargo-development-inputs parameter.
In its configure phase, this build system will make any source inputs
specified in the #:cargo-inputs and #:cargo-development-inputs
parameters available to cargo. It will also remove an included
Cargo.lock file to be recreated by cargo during the
build phase. The install phase installs any crate the
binaries if they are defined by the crate.
This variable is exported by (guix build-system copy). It supports
builds of simple packages that don’t require much compiling, mostly just
moving files around.
It adds much of the gnu-build-system packages to the set of inputs.
Because of this, the copy-build-system does not require all the
boilerplate code often needed for the trivial-build-system.
To further simplify the file installation process, an #:install-plan
argument is exposed to let the packager specify which files go where. The
install plan is a list of (source target
[filters]). filters are optional.
#:include, #:include-regexp, #:exclude,
#:exclude-regexp, only select files are installed depending on the
filters. Each filters is specified by a list of strings.
#:include, install all the files which the path suffix matches
at least one of the elements in the given list.
#:include-regexp, install all the files which the
subpaths match at least one of the regular expressions in the given list.
#:exclude and #:exclude-regexp filters
are the complement of their inclusion counterpart. Without #:include
flags, install all files but those matching the exclusion filters. If both
inclusions and exclusions are specified, the exclusions are done on top of
the inclusions.
In all cases, the paths relative to source are preserved within target.
Examples:
("foo/bar" "share/my-app/"): Install bar to share/my-app/bar.
("foo/bar" "share/my-app/baz"): Install bar to share/my-app/baz.
("foo/" "share/my-app"): Install the content of foo inside share/my-app,
e.g., install foo/sub/file to share/my-app/sub/file.
("foo/" "share/my-app" #:include ("sub/file")): Install only foo/sub/file to
share/my-app/sub/file.
("foo/sub" "share/my-app" #:include ("file")): Install foo/sub/file to
share/my-app/file.
This variable is exported by (guix build-system clojure). It
implements a simple build procedure for Clojure
packages using plain old compile in Clojure. Cross-compilation is
not supported yet.
It adds clojure, icedtea and zip to the set of inputs.
Different packages can be specified with the #:clojure, #:jdk
and #:zip parameters, respectively.
A list of source directories, test directories and jar names can be
specified with the #:source-dirs, #:test-dirs and
#:jar-names parameters, respectively. Compile directory and main
class can be specified with the #:compile-dir and #:main-class
parameters, respectively. Other parameters are documented below.
This build system is an extension of ant-build-system, but with the
following phases changed:
buildThis phase calls compile in Clojure to compile source files and runs
jar to create jars from both source files and compiled files
according to the include list and exclude list specified in
#:aot-include and #:aot-exclude, respectively. The exclude
list has priority over the include list. These lists consist of symbols
representing Clojure libraries or the special keyword #:all
representing all Clojure libraries found under the source directories. The
parameter #:omit-source? decides if source should be included into
the jars.
checkThis phase runs tests according to the include list and exclude list
specified in #:test-include and #:test-exclude, respectively.
Their meanings are analogous to that of #:aot-include and
#:aot-exclude, except that the special keyword #:all now
stands for all Clojure libraries found under the test directories. The
parameter #:tests? decides if tests should be run.
installThis phase installs all jars built previously.
Apart from the above, this build system also contains an additional phase:
install-docThis phase installs all top-level files with base name matching
%doc-regex. A different regex can be specified with the
#:doc-regex parameter. All files (recursively) inside the
documentation directories specified in #:doc-dirs are installed as
well.
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 dune). It supports
builds of packages using Dune, a build tool for
the OCaml programming language. It is implemented as an extension of the
ocaml-build-system which is described below. As such, the
#:ocaml and #:findlib parameters can be passed to this build
system.
It automatically adds the dune package to the set of inputs. Which
package is used can be specified with the #:dune parameter.
There is no configure phase because dune packages typically don’t
need to be configured. The #:build-flags parameter is taken as a
list of flags passed to the dune command during the build.
The #:jbuild? parameter can be passed to use the jbuild
command instead of the more recent dune command while building a
package. Its default value is #f.
The #:package parameter can be passed to specify a package name,
which is useful when a package contains multiple packages and you want to
build only one of them. This is equivalent to passing the -p
argument to dune.
This variable is exported by (guix build-system go). It implements a
build procedure for Go packages using the standard
Go
build mechanisms.
The user is expected to provide a value for the key #:import-path
and, in some cases, #:unpack-path. The
import path corresponds
to the file system path expected by the package’s build scripts and any
referring packages, and provides a unique way to refer to a Go package. It
is typically based on a combination of the package source code’s remote URI
and file system hierarchy structure. In some cases, you will need to unpack
the package’s source code to a different directory structure than the one
indicated by the import path, and #:unpack-path should be used in
such cases.
Packages that provide Go libraries should install their source code into the
built output. The key #:install-source?, which defaults to
#t, controls whether or not the source code is installed. It can be
set to #f for packages that only provide executable files.
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-wrapThe phase glib-or-gtk-wrap ensures that programs in bin/ are
able to find GLib “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-schemasThe phase glib-or-gtk-compile-schemas makes sure that all
GSettings schemas of GLib 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 build system is for Guile packages that consist exclusively of Scheme
code and that are so lean that they don’t even have a makefile, let alone a
configure script. It compiles Scheme code using guild
compile (see Compilation in GNU Guile Reference Manual) and
installs the .scm and .go files in the right place. It also
installs documentation.
This build system supports cross-compilation by using the --target
option of guild compile.
Packages built with guile-build-system must provide a Guile package
in their native-inputs field.
This variable is exported by (guix build-system julia). It
implements the build procedure used by julia
packages, which essentially is similar to running julia -e 'using
Pkg; Pkg.add(package)' in an environment where JULIA_LOAD_PATH
contains the paths to all Julia package inputs. Tests are run not run.
Julia packages require the source file-name to be the real name of
the package, correctly capitalized.
For packages requiring shared library dependencies, you may need to write
the /deps/deps.jl file manually. It’s usually a line of const
variable = /gnu/store/library.so for each dependency, plus a void function
check_deps() = nothing.
Some older packages that aren’t using Package.toml yet, will require
this file to be created, too. The function julia-create-package-toml
helps creating the file. You need to pass the outputs and the source of the
package, it’s name (the same as the file-name parameter), the package
uuid, the package version, and a list of dependencies specified by their
name and their uuid.
This variable is exported by (guix build-system minify). It
implements a minification procedure for simple JavaScript packages.
It adds uglify-js to the set of inputs and uses it to compress all
JavaScript files in the src directory. A different minifier package
can be specified with the #:uglify-js parameter, but it is expected
that the package writes the minified code to the standard output.
When the input JavaScript files are not all located in the src
directory, the parameter #:javascript-files can be used to specify a
list of file names to feed to the minifier.
This variable is exported by (guix build-system ocaml). It
implements a build procedure for OCaml packages,
which consists of choosing the correct set of commands to run for each
package. OCaml packages can expect many different commands to be run. This
build system will try some of them.
When the package has a setup.ml file present at the top-level, it
will run ocaml setup.ml -configure, ocaml setup.ml -build and
ocaml setup.ml -install. The build system will assume that this file
was generated by OASIS and will
take care of setting the prefix and enabling tests if they are not
disabled. You can pass configure and build flags with the
#:configure-flags and #:build-flags. The #:test-flags
key can be passed to change the set of flags used to enable tests. The
#:use-make? key can be used to bypass this system in the build and
install phases.
When the package has a configure file, it is assumed that it is a
hand-made configure script that requires a different argument format than in
the gnu-build-system. You can add more flags with the
#:configure-flags key.
When the package has a Makefile file (or #:use-make? is
#t), it will be used and more flags can be passed to the build and
install phases with the #:make-flags key.
Finally, some packages do not have these files and use a somewhat standard
location for its build system. In that case, the build system will run
ocaml pkg/pkg.ml or ocaml pkg/build.ml and take care of
providing the path to the required findlib module. Additional flags can be
passed via the #:build-flags key. Install is taken care of by
opam-installer. In this case, the opam package must be
added to the native-inputs field of the package definition.
Note that most OCaml packages assume they will be installed in the same
directory as OCaml, which is not what we want in guix. In particular, they
will install .so files in their module’s directory, which is usually
fine because it is in the OCaml compiler directory. In guix though, these
libraries cannot be found and we use CAML_LD_LIBRARY_PATH. This
variable points to lib/ocaml/site-lib/stubslibs and this is where
.so libraries should be installed.
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 that their PYTHONPATH
environment variable points to all the Python libraries they depend on.
Which Python package is used to perform the build can be specified with the
#:python parameter. This is a useful way to force a package to be
built for a specific version of the Python interpreter, which might be
necessary if the package is only compatible with a single interpreter
version.
By default guix calls setup.py under control of setuptools,
much like pip does. Some packages are not compatible with
setuptools (and pip), thus you can disable this by setting the
#:use-setuptools? parameter to #f.
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 qt). It is intended
for use with applications using Qt or KDE.
This build system adds the following two phases to the ones defined by
cmake-build-system:
check-setupThe phase check-setup prepares the environment for running the checks
as commonly used by Qt test programs. For now this only sets some
environment variables: QT_QPA_PLATFORM=offscreen,
DBUS_FATAL_WARNINGS=0 and CTEST_OUTPUT_ON_FAILURE=1.
This phase is added before the check phase. It’s a separate phase to
ease adjusting if necessary.
qt-wrapThe phase qt-wrap searches for Qt5 plugin paths, QML paths and some
XDG in the inputs and output. In case some path is found, all programs in
the output’s bin/, sbin/, libexec/ and
lib/libexec/ directories are wrapped in scripts defining the
necessary environment variables.
It is possible to exclude specific package outputs from that wrapping
process by listing their names in the #:qt-wrap-excluded-outputs
parameter. This is useful when an output is known not to contain any Qt
binaries, and where wrapping would gratuitously add a dependency of that
output on Qt, KDE, or such.
This phase is added after the install phase.
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 rakudo). It
implements the build procedure used by Rakudo
for Perl6 packages. It installs the package to
/gnu/store/…/NAME-VERSION/share/perl6 and installs the
binaries, library files and the resources, as well as wrap the files under
the bin/ directory. Tests can be skipped by passing #f to the
tests? parameter.
Which rakudo package is used can be specified with rakudo. Which
perl6-tap-harness package used for the tests can be specified with
#:prove6 or removed by passing #f to the with-prove6?
parameter. Which perl6-zef package used for tests and installing can be
specified with #:zef or removed by passing #f to the
with-zef? parameter.
This variable is exported by (guix build-system texlive). It is used
to build TeX packages in batch mode with a specified engine. The build
system sets the TEXINPUTS variable to find all TeX source files in
the inputs.
By default it runs luatex on all files ending on ins. A
different engine and format can be specified with the #:tex-format
argument. Different build targets can be specified with the
#:build-targets argument, which expects a list of file names. The
build system adds only texlive-bin and texlive-latex-base
(both from (gnu packages tex) to the inputs. Both can be overridden
with the arguments #:texlive-bin and #:texlive-latex-base,
respectively.
The #:tex-directory parameter tells the build system where to install
the built files under the texmf tree.
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 scons). It
implements the build procedure used by the SCons software construction
tool. This build system runs scons to build the package, scons
test to run tests, and then scons install to install the package.
Additional flags to be passed to scons can be specified with the
#:scons-flags parameter. The default build and install targets can
be overridden with #:build-targets and #:install-targets
respectively. The version of Python used to run SCons can be specified by
selecting the appropriate SCons package with the #:scons 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 dub). It implements
the Dub build procedure used by D packages, which involves running dub
build and dub run. Installation is done by copying the files
manually.
Which D compiler is used can be specified with the #:ldc parameter
which defaults to ldc.
This variable is exported by (guix build-system emacs). It
implements an installation procedure similar to the packaging system of
Emacs itself (see Packages in The GNU Emacs Manual).
It first creates the package-autoloads.el
This variable is exported by (guix build-system font). It implements
an installation procedure for font packages where upstream provides
pre-compiled TrueType, OpenType, etc. font files that merely need to be
copied into place. It copies font files to standard locations in the output
directory.
This variable is exported by (guix build-system meson). It
implements the build procedure for packages that use
Meson as their build system.
It adds both Meson and Ninja to the set of
inputs, and they can be changed with the parameters #:meson and
#:ninja if needed. The default Meson is meson-for-build,
which is special because it doesn’t clear the RUNPATH of binaries and
libraries when they are installed.
This build system is an extension of gnu-build-system, but with the
following phases changed to some specific for Meson:
configureThe phase runs meson with the flags specified in
#:configure-flags. The flag --build-type is always set to
plain unless something else is specified in #:build-type.
buildThe phase runs ninja to build the package in parallel by default, but
this can be changed with #:parallel-build?.
checkThe phase runs ninja with the target specified in
#:test-target, which is "test" by default.
installThe phase runs ninja install and can not be changed.
Apart from that, the build system also adds the following phases:
fix-runpathThis phase ensures that all binaries can find the libraries they need. It
searches for required libraries in subdirectories of the package being
built, and adds those to RUNPATH where needed. It also removes
references to libraries left over from the build phase by
meson-for-build, such as test dependencies, that aren’t actually
required for the program to run.
glib-or-gtk-wrapThis phase is the phase provided by glib-or-gtk-build-system, and it
is not enabled by default. It can be enabled with #:glib-or-gtk?.
glib-or-gtk-compile-schemasThis phase is the phase provided by glib-or-gtk-build-system, and it
is not enabled by default. It can be enabled with #:glib-or-gtk?.
linux-module-build-system allows building Linux kernel modules.
This build system is an extension of gnu-build-system, but with the
following phases changed:
configureThis phase configures the environment so that the Linux kernel’s Makefile can be used to build the external kernel module.
buildThis phase uses the Linux kernel’s Makefile in order to build the external kernel module.
installThis phase uses the Linux kernel’s Makefile in order to install the external kernel module.
It is possible and useful to specify the Linux kernel to use for building the module (in the "arguments" form of a package using the linux-module-build-system, use the key #:linux to specify it).
This variable is exported by (guix build-system node). It implements
the build procedure used by Node.js, which
implements an approximation of the npm install command, followed by
an npm test command.
Which Node.js package is used to interpret the npm commands can be
specified with the #:node parameter which defaults to node.
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 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: Хранилище, Previous: Описание пакетов, Up: Программный интерфейс [Contents][Index]