Delete the stdenv section

It's outdated and better covered in the Nixpkgs manual.
This commit is contained in:
Eelco Dolstra 2014-12-14 01:39:32 +01:00
parent 6466d56f42
commit 68b4717873
7 changed files with 21 additions and 105 deletions

View file

@ -1,26 +0,0 @@
<section xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
version="5.0"
xml:id="sec-custom-builder">
<title>Customizing the Generic Builder</title>
<para>The operation of the generic builder can be modified in many
places by setting certain variables. These <emphasis>hook
variables</emphasis> are typically set to the name of some shell
function defined by you. For instance, to perform some additional
steps after <command>make install</command> you would set the
<varname>postInstall</varname> variable:
<programlisting>
postInstall=myPostInstall
myPostInstall() {
mkdir $out/share/extra
cp extrafiles/* $out/share/extra
}</programlisting>
</para>
</section>

View file

@ -6,13 +6,14 @@
<title>Debugging Build Failures</title>
<para>At the beginning of each phase, the set of all shell variables
is written to the file <filename>env-vars</filename> at the top-level
build directory. This is useful for debugging: it allows you to
recreate the environment in which a build was performed. For
instance, if a build fails, then assuming you used the
<option>-K</option> flag, you can go to the output directory and
<quote>switch</quote> to the environment of the builder:
<para>At the beginning of each phase of the build (such as unpacking,
building or installing), the set of all shell variables is written to
the file <filename>env-vars</filename> at the top-level build
directory. This is useful for debugging: it allows you to recreate
the environment in which a build was performed. For instance, if a
build fails, then assuming you used the <option>-K</option> flag, you
can go to the output directory and <quote>switch</quote> to the
environment of the builder:
<screen>
$ nix-build -K ./foo.nix

View file

@ -110,12 +110,12 @@ buildInputs = [ pkg pkg.headers ];
</itemizedlist>
<para>The function <function>mkDerivation</function> in the standard
environment is a wrapper around <function>derivation</function> that
adds a default value for <varname>system</varname> and always uses
Bash as the builder, to which the supplied builder is passed as a
command-line argument. See <xref linkend='sec-standard-environment'
/>.</para>
<para>The function <function>mkDerivation</function> in the Nixpkgs
standard environment is a wrapper around
<function>derivation</function> that adds a default value for
<varname>system</varname> and always uses Bash as the builder, to
which the supplied builder is passed as a command-line argument. See
the Nixpkgs manual for details.</para>
<para>The builder is executed as follows:

View file

@ -71,7 +71,7 @@ genericBuild <co xml:id='ex-hello-builder2-co-3' /></programlisting>
generic builder is smart enough to figure out whether to unpack
the sources using <command>gzip</command>,
<command>bzip2</command>, etc. It can be customised in many ways;
see <xref linkend='sec-standard-environment' />.</para>
see the Nixpkgs manual for details.</para>
</callout>

View file

@ -83,4 +83,6 @@ Just pass the option <link linkend='opt-max-jobs'><option>-j
in parallel, or set. Typically this should be the number of
CPUs.</para>
<xi:include href="debug-build.xml" />
</section>

View file

@ -1,60 +0,0 @@
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
version="5.0"
xml:id='sec-standard-environment'>
<title>The Standard Environment</title>
<para>The standard environment is used by passing it as an input
called <envar>stdenv</envar> to the derivation, and then doing
<programlisting>
source $stdenv/setup</programlisting>
at the top of the builder.</para>
<para>Apart from adding the aforementioned commands to the
<envar>PATH</envar>, <filename>setup</filename> also does the
following:
<itemizedlist>
<listitem><para>All input packages specified in the
<envar>buildInputs</envar> environment variable have their
<filename>/bin</filename> subdirectory added to <envar>PATH</envar>,
their <filename>/include</filename> subdirectory added to the C/C++
header file search path, and their <filename>/lib</filename>
subdirectory added to the linker search path. This can be extended.
For instance, when the <command>pkgconfig</command> package is
used, the subdirectory <filename>/lib/pkgconfig</filename> of each
input is added to the <envar>PKG_CONFIG_PATH</envar> environment
variable.</para></listitem>
<listitem><para>The environment variable
<envar>NIX_CFLAGS_STRIP</envar> is set so that the compiler strips
debug information from object files. This can be disabled by
setting <envar>NIX_STRIP_DEBUG</envar> to
<literal>0</literal>.</para></listitem>
</itemizedlist>
</para>
<para>The <filename>setup</filename> script also exports a function
called <function>genericBuild</function> that knows how to build
typical Autoconf-style packages. It can be customised to perform
builds for any type of package. It is advisable to use
<function>genericBuild</function> since it provides facilities that
are almost always useful such as unpacking of sources, patching of
sources, nested logging, etc.</para>
<para>The definitive, up-to-date documentation of the generic builder
is the source itself, which resides in
<filename>pkgs/stdenv/generic/setup.sh</filename>.</para>
<xi:include href="custom-builder.xml" />
<xi:include href="debug-build.xml" />
</chapter>

View file

@ -22,6 +22,5 @@ manual</link>.</para></note>
<xi:include href="simple-expression.xml" />
<xi:include href="expression-language.xml" />
<xi:include href="standard-env.xml" />
</part>