mirror of
https://github.com/privatevoid-net/nix-super.git
synced 2024-11-25 15:26:17 +02:00
Delete the stdenv section
It's outdated and better covered in the Nixpkgs manual.
This commit is contained in:
Eelco Dolstra
parent
6466d56f42
commit
68b4717873
7 changed files with 21 additions and 105 deletions
|
|
@ -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>
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
@ -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>
|
||||
|
|
@ -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>
|
||||
|
|
|
|||
Loading…
Reference in a new issue