* More manual updates.

This commit is contained in:
Eelco Dolstra 2005-04-07 10:47:58 +00:00
parent f1ae10b992
commit 57d023a184
6 changed files with 153 additions and 29 deletions

View file

@ -5,9 +5,10 @@ XSLTPROC = $(ENV) $(xsltproc) $(xmlflags) --catalogs \
--param section.autolabel 1 \ --param section.autolabel 1 \
--param section.label.includes.component.label 1 \ --param section.label.includes.component.label 1 \
--param html.stylesheet \'style.css\' \ --param html.stylesheet \'style.css\' \
--param xref.with.number.and.title 0 --param xref.with.number.and.title 0 \
--param toc.section.depth 3
man1_MANS = nix-env.1 nix-store.1 nix-instantiate.1 \ man1_MANS = nix-env.1 nix-build.1 nix-store.1 nix-instantiate.1 \
nix-collect-garbage.1 nix-push.1 nix-pull.1 \ nix-collect-garbage.1 nix-push.1 nix-pull.1 \
nix-prefetch-url.1 nix-prefetch-url.1

View file

@ -46,7 +46,7 @@
</glossentry> </glossentry>
<glossentry><glossterm>substitute</glossterm> <glossentry id="gloss-substitute"><glossterm>substitute</glossterm>
<glossdef><para>A substitute is a command invocation stored in the <glossdef><para>A substitute is a command invocation stored in the
Nix database that describes how to build a store object, bypassing Nix database that describes how to build a store object, bypassing
@ -94,6 +94,16 @@
</glossentry> </glossentry>
<glossentry id="gloss-validity"><glossterm>validity</glossterm>
<glossdef><para>A store path is considered
<emphasis>valid</emphasis> if it exists in the file system, is
listed in the Nix database as being valid, and if all paths in its
closure are also valid.</para></glossdef>
</glossentry>
</glosslist> </glosslist>

View file

@ -39,11 +39,15 @@
<title>nix-env</title> <title>nix-env</title>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="nix-env.xml" /> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="nix-env.xml" />
</sect1> </sect1>
<sect1 id="sec-nix-build">
<title>nix-build</title>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="nix-build.xml" />
</sect1>
<sect1> <sect1>
<title>nix-store</title> <title>nix-store</title>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="nix-store.xml" /> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="nix-store.xml" />
</sect1> </sect1>
<sect1> <sect1 id="sec-nix-instantiate">
<title>nix-instantiate</title> <title>nix-instantiate</title>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="nix-instantiate.xml" /> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="nix-instantiate.xml" />
</sect1> </sect1>

72
doc/manual/nix-build.xml Normal file
View file

@ -0,0 +1,72 @@
<refentry>
<refnamediv>
<refname>nix-build</refname>
<refpurpose>build a Nix expression</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>nix-build</command>
<arg choice='plain' rep='repeat'><replaceable>paths</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsection><title>Description</title>
<para>The <command>nix-build</command> command builds the derivations
described by the Nix expressions in <replaceable>paths</replaceable>.
If the build succeeds, it places a symlink to the result in the
current directory. The symlink is called <filename>result</filename>.
If there are multiple Nix expressions, or the Nix expressions evaluate
to multiple derivations, multiple sequentially numbered symlinks are
created (<filename>result</filename>, <filename>result-2</filename>,
and so on).</para>
<note><para><command>nix-build</command> is essentially a wrapper
around <link
linkend="sec-nix-instantiate"><command>nix-instantiate</command></link>
(to translate a high-level Nix expression to a low-level store
derivation) and <link
linkend="rsec-nix-store-realise"><command>nix-store
--realise</command></link> (to build the store
derivation).</para></note>
<warning><para>The result of the build is automatically registered as
a root of the Nix garbage collector. This root disappears
automatically when the <filename>result</filename> symlink is deleted
or renamed. So dont rename the symlink.</para></warning>
</refsection>
<refsection><title>Options</title>
<variablelist>
<varlistentry><term><option>--add-drv-link</option></term>
<listitem><para>Add a symlink in the current directory to the
store derivation produced by <command>nix-instantiate</command>.
The symlink is called <filename>derivation</filename> (which is
numbered in the case of multiple derivations). The derivation is
a root of the garbage collector until the symlink is deleted or
renamed.</para></listitem>
</varlistentry>
<varlistentry><term><option>--no-link</option></term>
<listitem><para>Do not create a symlink to the output path. Note
that as a result the output does not become a root of the garbage
collector, and so might be deleted by <command>nix-store
--gc</command>.</para></listitem>
</varlistentry>
</variablelist>
</refsection>
</refentry>

View file

@ -45,7 +45,7 @@ linkend="sec-common-options" /> for a list of common options.</para>
<varlistentry id="opt-add-root"><term><option>--add-root</option> <replaceable>path</replaceable></term> <varlistentry id="opt-add-root"><term><option>--add-root</option> <replaceable>path</replaceable></term>
<listitem><para>Causes the result of a build action <listitem><para>Causes the result of a realisation
(<option>--realise</option> and <option>--force-realise</option>) (<option>--realise</option> and <option>--force-realise</option>)
to be registered as a root of the garbage collector (see <xref to be registered as a root of the garbage collector (see <xref
linkend="ssec-gc-roots" />). The root is stored in linkend="ssec-gc-roots" />). The root is stored in
@ -54,7 +54,12 @@ linkend="sec-common-options" /> for a list of common options.</para>
typically in a subdirectory of typically in a subdirectory of
<filename>/nix/var/nix/gcroots/</filename>) <filename>/nix/var/nix/gcroots/</filename>)
<emphasis>unless</emphasis> the <option>--indirect</option> flag <emphasis>unless</emphasis> the <option>--indirect</option> flag
is used.</para></listitem> is used.</para>
<para>If there are multiple results, then multiple symlinks will
be created by sequentially numbering symlinks beyond the first one
(e.g., <filename>foo</filename>, <filename>foo-2</filename>,
<filename>foo-3</filename>, and so on).</para></listitem>
</varlistentry> </varlistentry>
@ -121,25 +126,56 @@ lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r1134
<refsection><title>Description</title> <refsection><title>Description</title>
<para>The operation <option>--install</option> realises in the file <para>The operation <option>--realise</option> essentially “builds”
system the store expressions stored in the specified store paths. Realisation is a somewhat overloaded term:
<replaceable>paths</replaceable>. If these expressions are derivation
expressions, they are first <emphasis>normalised</emphasis> into a
closure expression. This may happen in two ways. First, the
corresponding closure expression (the <emphasis>successor</emphasis>)
may already known (either because the build has already been
performed, or because a successor was explicitly registered through
the <option>--successor</option> operation). Otherwise, the build
action described by the derivation is performed, and a closure
expression is computed by scanning the result of the build for
references to other paths in the store.</para>
<para>The paths of the closure expression corresponding to each <itemizedlist>
expression in <replaceable>paths</replaceable> is printed on standard
output.</para> <listitem><para>If the store path is a
<emphasis>derivation</emphasis>, realisation ensures that the output
paths of the derivation are <link
linkend="gloss-validity">valid</link> (i.e., the output path and its
closure exist in the file system). This can be done in several
ways. First, it is possible that the outputs are already valid, in
which case we are done immediately. Otherwise, there may be <link
linkend="gloss-substitute">substitutes</link> that produce the
outputs (e.g., by downloading them). Finally, the outputs can be
produced by performing the build action described by the
derivation.</para></listitem>
<listitem><para>If the store path is not a derivation, realisation
ensures that the specified path is valid (i.e., it and its closure
exist in the file system). If the path is already valid, we are
done immediately. Otherwise, the path and any missing paths in its
closure may be produced through substitutes. If there are no
(succesful) subsitutes, realisation fails.</para></listitem>
</itemizedlist>
</para>
<para>The output path of each derivation is printed on standard
output. (For non-derivations argument, the argument itself is
printed.)</para>
</refsection> </refsection>
<refsection><title>Examples</title>
<para>This operation is typically used to build store derivations
produced by <link
linkend="sec-nix-instantiate"><command>nix-instantiate</command></link>:
<screen>
$ nix-store -r $(nix-instantiate ./foo.nix)</screen>
This is essentially what <link
linkend="sec-nix-build"><command>nix-build</command></link> does.</para>
</refsection>
</refsection> </refsection>
@ -168,7 +204,7 @@ output.</para>
<para>Without additional flags, the operation <option>--gc</option> <para>Without additional flags, the operation <option>--gc</option>
performs a garbage collection on the Nix store. That is, all paths in performs a garbage collection on the Nix store. That is, all paths in
the Nix store not reachable via file system references from a set of the Nix store not reachable via file system references from a set of
<quote>roots</quote>, are deleted.</para> “roots”, are deleted.</para>
<para>The following suboperations may be specified:</para> <para>The following suboperations may be specified:</para>
@ -184,9 +220,9 @@ the Nix store not reachable via file system references from a set of
<varlistentry><term><option>--print-live</option></term> <varlistentry><term><option>--print-live</option></term>
<listitem><para>This operation prints on standard output the set <listitem><para>This operation prints on standard output the set
of <quote>live</quote> store paths, which are all the store paths of “live” store paths, which are all the store paths reachable
reachable from the roots. Live paths should never be deleted, from the roots. Live paths should never be deleted, since that
since that would break consistency — it would become possible that would break consistency — it would become possible that
applications are installed that reference things that are no applications are installed that reference things that are no
longer present in the store.</para></listitem> longer present in the store.</para></listitem>
@ -195,9 +231,9 @@ the Nix store not reachable via file system references from a set of
<varlistentry><term><option>--print-dead</option></term> <varlistentry><term><option>--print-dead</option></term>
<listitem><para>This operation prints out on standard output the <listitem><para>This operation prints out on standard output the
set of <quote>dead</quote> store paths, which is just the opposite set of “dead” store paths, which is just the opposite of the set
of the set of live paths: any path in the store that is not live of live paths: any path in the store that is not live (with
(with respect to the roots) is dead.</para></listitem> respect to the roots) is dead.</para></listitem>
</varlistentry> </varlistentry>

View file

@ -447,7 +447,8 @@ following:
(import pkgs/system/i686-linux.nix).hello</programlisting> (import pkgs/system/i686-linux.nix).hello</programlisting>
Call it <filename>test.nix</filename>. You can then build it without Call it <filename>test.nix</filename>. You can then build it without
installing it using the command <command>nix-build</command>: installing it using the command <link
linkend="sec-nix-build"><command>nix-build</command></link>:
<screen> <screen>
$ nix-build ./test.nix $ nix-build ./test.nix