3
0
Fork 0
forked from mirrors/nixpkgs
nixpkgs/doc/stdenv.xml

363 lines
12 KiB
XML
Raw Normal View History

<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xml:id="chap-stdenv">
<title>The Standard Environment</title>
<para>The standard build environment in the Nix Packages collection
provides a environment for building Unix packages that does a lot of
common build tasks automatically. In fact, for Unix packages that use
the standard <literal>./configure; make; make install</literal> build
interface, you dont need to write a build script at all; the standard
environment does everything automatically. If
<literal>stdenv</literal> doesnt do what you need automatically, you
can easily customise or override the various build phases.</para>
<section><title>Using <literal>stdenv</literal></title>
<para>To build a package with the standard environment, you use the
function <varname>stdenv.mkDerivation</varname>, instead of the
primitive built-in function <varname>derivation</varname>, e.g.
<programlisting>
stdenv.mkDerivation {
name = "libfoo-1.2.3";
src = fetchurl {
url = http://example.org/libfoo-1.2.3.tar.bz2;
md5 = "e1ec107956b6ddcb0b8b0679367e9ac9";
};
}</programlisting>
(<varname>stdenv</varname> needs to be in scope, so if you write this
in a separate Nix expression from
<filename>pkgs/all-packages.nix</filename>, you need to pass it as a
function argument.) Specifying a <varname>name</varname> and a
<varname>src</varname> is the absolute minimum you need to do. Many
packages have dependencies that are not provided in the standard
environment. Its usually sufficient to specify those dependencies in
the <varname>buildInputs</varname> attribute:
<programlisting>
stdenv.mkDerivation {
name = "libfoo-1.2.3";
...
buildInputs = [libbar perl ncurses];
}</programlisting>
This attribute ensures that the <filename>bin</filename>
subdirectories of these packages appear in the <envar>PATH</envar>
environment variable during the build, that their
<filename>include</filename> subdirectories are searched by the C
compiler, and so on. (See <xref linkend="ssec-setup-hooks"/> for
details.)</para>
<para>Often it is necessary to override or modify some aspect of the
build. To make this easier, the standard environment breaks the
package build into a number of <emphasis>phases</emphasis>, all of
which can be overriden or modified individually: unpacking the
sources, applying patches, configuring, building, and installing.
(There are some others; see <xref linkend="ssec-stdenv-phases"/>.)
For instance, a package that doesnt supply a makefile but instead has
to be compiled “manually” could be handled like this:
<programlisting>
stdenv.mkDerivation {
name = "fnord-4.5";
...
buildPhase = ''
gcc foo.c -o foo
'';
installPhase = ''
ensureDir $out/bin
cp foo $out/bin
'';
}</programlisting>
(Note the use of <literal>''</literal>-style string literals, which
are very convenient for large multi-line script fragments because they
dont need escaping of <literal>"</literal> and <literal>\</literal>,
and because indentation is intelligently removed.)</para>
<para>There are many other attributes to customise the build. These
are listed in <xref linkend="ssec-stdenv-attributes"/>.</para>
<para>While the standard environment provides a generic builder, you
can still supply your own build script:
<programlisting>
stdenv.mkDerivation {
name = "libfoo-1.2.3";
...
builder = ./builder.sh;
}</programlisting>
where the builder can do anything it wants, but typically starts with
<programlisting>
source $stdenv/setup
</programlisting>
to let <literal>stdenv</literal> set up the environment (e.g., process
the <varname>buildInputs</varname>). If you want, you can still use
<literal>stdenv</literal>s generic builder:
<programlisting>
source $stdenv/setup
buildPhase() {
echo "... this is my custom build phase ..."
gcc foo.c -o foo
}
installPhase() {
ensureDir $out/bin
cp foo $out/bin
}
genericBuild
</programlisting>
</para>
</section>
<section><title>Tools provided by <literal>stdenv</literal></title>
<para>The standard environment provides the following packages:
<itemizedlist>
<listitem><para>The GNU C Compiler, configured with C and C++
support.</para></listitem>
<listitem><para>GNU coreutils (contains a few dozen standard Unix
commands).</para></listitem>
<listitem><para>GNU findutils (contains
<command>find</command>).</para></listitem>
<listitem><para>GNU diffutils (contains <command>diff</command>,
<command>cmp</command>).</para></listitem>
<listitem><para>GNU <command>sed</command>.</para></listitem>
<listitem><para>GNU <command>grep</command>.</para></listitem>
<listitem><para>GNU <command>awk</command>.</para></listitem>
<listitem><para>GNU <command>tar</command>.</para></listitem>
<listitem><para><command>gzip</command> and
<command>bzip2</command>.</para></listitem>
<listitem><para>GNU Make. It has been patched to provide
<quote>nested</quote> output that can be fed into the
<command>nix-log2xml</command> command and
<command>log2html</command> stylesheet to create a structured,
readable output of the build steps performed by
Make.</para></listitem>
<listitem><para>Bash. This is the shell used for all builders in
the Nix Packages collection. Not using <command>/bin/sh</command>
removes a large source of portability problems.</para></listitem>
<listitem><para>The <command>patch</command>
command.</para></listitem>
</itemizedlist>
</para>
<para>On Linux, <literal>stdenv</literal> also includes the
<command>patchelf</command> utility.</para>
</section>
<section xml:id="ssec-stdenv-phases"><title>Build phases</title>
<para>The generic builder has a number of <emphasis>phases</emphasis>.
Each phase can be overriden in its entirety either by setting the
environment variable
<varname><replaceable>name</replaceable>Phase</varname> to a string
containing some shell commands to be executed, or by redefining the
shell function
<varname><replaceable>name</replaceable>Phase</varname>. The former
is convenient to override a phase from the derivation, while the
latter is convenient from a build script.</para>
<para>The phases are:
<itemizedlist>
<listitem>
<para><function>unpackPhase</function> unpacks the source files
listed in the <envar>src</envar> environment variable to the
current directory. It supports <filename>tar</filename> files,
optionally compressed with <command>gzip</command> or
<command>bzip2</command>; Zip files (but note that the
<command>unzip</command> command is not a part of the standard
environment; you should add it as a build input yourself); and
unpacked source trees (i.e., directories; they are copied
verbatim). You can add support for other file types by setting
the <varname>findUnpacker</varname> hook. This hook should set
the variable <varname>unpackCmd</varname> to contain the command
to be executed to unpack the file.</para>
<para>After running <function>unpackPhase</function>, the generic
builder changes the current directory to the directory created by
unpacking the sources. If there are multiple source directories,
you should set <varname>sourceRoot</varname> to the name of the
intended directory.</para>
<para>It also calls the hook <varname>postUnpack</varname> after
unpacking.</para>
</listitem>
<listitem><para><function>patchPhase</function> calls the
<command>patch</command> command with the <option>-p1</option>
option (overridable via <envar>patchFlags</envar>) for each patch
file listed in the <envar>patches</envar>
variable.</para></listitem>
<listitem>
<para><function>configurePhase</function> runs the script called
<filename>configure</filename> in the current directory with a
<option>--prefix</option> set to the output path. You can add
additional flags through the <varname>configureFlags</varname>
variable. If <filename>configure</filename> does not exist,
nothing happens.</para>
<para>Before and after running <filename>configure</filename>, the
hooks <varname>preConfigure</varname> and
<varname>postConfigure</varname> are called, respectively.</para>
</listitem>
<listitem>
<para><function>buildPhase</function> calls
<command>make</command>. You can set flags for
<command>make</command> through the <varname>makeFlags</varname>
variable.</para>
<para>Before and after running <command>make</command>, the hooks
<varname>preBuild</varname> and <varname>postBuild</varname> are
called, respectively.</para>
</listitem>
<listitem><para><function>checkPhase</function> calls <command>make
check</command>, but only if the <varname>doCheck</varname> variable
is set to <literal>1</literal>. Additional flags can be set through
the <varname>checkFlags</varname> variable.</para></listitem>
<listitem>
<para><function>installPhase</function> calls <command>make
install</command>. Additional flags can be set through the
<varname>installFlags</varname> variable.</para>
<para>Before and after running <command>make install</command>,
the hooks <varname>preInstall</varname> and
<varname>postInstall</varname> are called, respectively.</para>
</listitem>
<listitem>
<para><function>fixupPhase</function> cleans up the
installed files in various ways:
<itemizedlist>
<listitem><para>It moves the <filename>man/</filename>,
<filename>doc/</filename> and <filename>info/</filename>
subdirectories of <envar>$out</envar> to
<filename>share/</filename>.</para></listitem>
<listitem><para>It strips libraries and executables of debug
information.</para></listitem>
<listitem><para>On Linux, it applies the
<command>patchelf</command> command to ELF executables and
libraries to remove unused directories from the
<literal>RPATH</literal> in order to prevent unnecessary
dependencies.</para></listitem>
<listitem><para>It rewrites the interpreter paths of shell
scripts to paths found in <envar>PATH</envar>. E.g.,
<filename>/usr/bin/perl</filename> will be rewritten to
<filename>/nix/store/<replaceable>some-perl</replaceable>/bin/perl</filename>
found in <envar>PATH</envar>.</para></listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para><function>distPhase</function> calls <command>make
dist</command>, but only if the <varname>doDist</varname> variable
is set to <literal>1</literal>. Additional flags can be set
through the <varname>distFlags</varname> variable. The resulting
tarball is copied to the <filename>/tarballs</filename>
subdirectory of the output path.</para>
<para>Before and after running <command>make dist</command>, the
hooks <varname>preDist</varname> and <varname>postDist</varname>
are called, respectively.</para>
</listitem>
</itemizedlist>
</para>
<para>You can change the order in which phases are executed, or add
new phases, by setting the <varname>phases</varname> variable. The
default is <literal>patchPhase configurePhase buildPhase checkPhase
installPhase distPhase</literal>.</para>
</section>
<section xml:id="ssec-stdenv-attributes"><title>Attributes</title>
<para></para>
</section>
<section xml:id="ssec-setup-hooks"><title>Package setup hooks</title>
<para></para>
</section>
<section><title>Purity in Nixpkgs</title>
<para>[measures taken to prevent dependencies on packages outside the
store, and what you can do to prevent them]</para>
<para>GCC doesn't search in locations such as
<filename>/usr/include</filename>. In fact, attempts to add such
directories through the <option>-I</option> flag are filtered out.
Likewise, the linker (from GNU binutils) doesn't search in standard
locations such as <filename>/usr/lib</filename>. Programs built on
Linux are linked against a GNU C Library that likewise doesn't search
in the default system locations.</para>
</section>
</chapter>