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

View file

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

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 generic builder is smart enough to figure out whether to unpack
the sources using <command>gzip</command>, the sources using <command>gzip</command>,
<command>bzip2</command>, etc. It can be customised in many ways; <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> </callout>
@ -95,4 +95,4 @@ In fact, <varname>mkDerivation</varname> provides a default builder
that looks exactly like that, so it is actually possible to omit the that looks exactly like that, so it is actually possible to omit the
builder for Hello entirely.</para> builder for Hello entirely.</para>
</section> </section>

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 in parallel, or set. Typically this should be the number of
CPUs.</para> CPUs.</para>
</section> <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="simple-expression.xml" />
<xi:include href="expression-language.xml" /> <xi:include href="expression-language.xml" />
<xi:include href="standard-env.xml" />
</part> </part>