* More manual updates.
This commit is contained in:
		
							parent
							
								
									f1ae10b992
								
							
						
					
					
						commit
						57d023a184
					
				
					 6 changed files with 153 additions and 29 deletions
				
			
		| 
						 | 
				
			
			@ -5,9 +5,10 @@ XSLTPROC = $(ENV) $(xsltproc) $(xmlflags) --catalogs \
 | 
			
		|||
 --param section.autolabel 1 \
 | 
			
		||||
 --param section.label.includes.component.label 1 \
 | 
			
		||||
 --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-prefetch-url.1
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -46,7 +46,7 @@
 | 
			
		|||
</glossentry>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
<glossentry><glossterm>substitute</glossterm>
 | 
			
		||||
<glossentry id="gloss-substitute"><glossterm>substitute</glossterm>
 | 
			
		||||
 | 
			
		||||
  <glossdef><para>A substitute is a command invocation stored in the
 | 
			
		||||
  Nix database that describes how to build a store object, bypassing
 | 
			
		||||
| 
						 | 
				
			
			@ -94,6 +94,16 @@
 | 
			
		|||
</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>
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -39,11 +39,15 @@
 | 
			
		|||
      <title>nix-env</title>
 | 
			
		||||
      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="nix-env.xml" />
 | 
			
		||||
    </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>
 | 
			
		||||
      <title>nix-store</title>
 | 
			
		||||
      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="nix-store.xml" />
 | 
			
		||||
    </sect1>
 | 
			
		||||
    <sect1>
 | 
			
		||||
    <sect1 id="sec-nix-instantiate">
 | 
			
		||||
      <title>nix-instantiate</title>
 | 
			
		||||
      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="nix-instantiate.xml" />
 | 
			
		||||
    </sect1>
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
							
								
								
									
										72
									
								
								doc/manual/nix-build.xml
									
										
									
									
									
										Normal file
									
								
							
							
						
						
									
										72
									
								
								doc/manual/nix-build.xml
									
										
									
									
									
										Normal 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 don’t 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>
 | 
			
		||||
| 
						 | 
				
			
			@ -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>
 | 
			
		||||
 | 
			
		||||
    <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>)
 | 
			
		||||
    to be registered as a root of the garbage collector (see <xref
 | 
			
		||||
    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
 | 
			
		||||
    <filename>/nix/var/nix/gcroots/</filename>)
 | 
			
		||||
    <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>
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -121,25 +126,56 @@ lrwxrwxrwx    1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r1134
 | 
			
		|||
 | 
			
		||||
<refsection><title>Description</title>
 | 
			
		||||
            
 | 
			
		||||
<para>The operation <option>--install</option> realises in the file
 | 
			
		||||
system the store expressions stored in
 | 
			
		||||
<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 operation <option>--realise</option> essentially “builds”
 | 
			
		||||
the specified store paths.  Realisation is a somewhat overloaded term:
 | 
			
		||||
 | 
			
		||||
<para>The paths of the closure expression corresponding to each
 | 
			
		||||
expression in <replaceable>paths</replaceable> is printed on standard
 | 
			
		||||
output.</para>
 | 
			
		||||
<itemizedlist>
 | 
			
		||||
 | 
			
		||||
  <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><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>
 | 
			
		||||
 | 
			
		||||
  
 | 
			
		||||
| 
						 | 
				
			
			@ -168,7 +204,7 @@ output.</para>
 | 
			
		|||
<para>Without additional flags, the operation <option>--gc</option>
 | 
			
		||||
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
 | 
			
		||||
<quote>roots</quote>, are deleted.</para>
 | 
			
		||||
“roots”, are deleted.</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>
 | 
			
		||||
  
 | 
			
		||||
    <listitem><para>This operation prints on standard output the set
 | 
			
		||||
    of <quote>live</quote> store paths, which are all the store paths
 | 
			
		||||
    reachable from the roots.  Live paths should never be deleted,
 | 
			
		||||
    since that would break consistency — it would become possible that
 | 
			
		||||
    of “live” store paths, which are all the store paths reachable
 | 
			
		||||
    from the roots.  Live paths should never be deleted, since that
 | 
			
		||||
    would break consistency — it would become possible that
 | 
			
		||||
    applications are installed that reference things that are no
 | 
			
		||||
    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>
 | 
			
		||||
  
 | 
			
		||||
    <listitem><para>This operation prints out on standard output the
 | 
			
		||||
    set of <quote>dead</quote> store paths, which is just the opposite
 | 
			
		||||
    of the set of live paths: any path in the store that is not live
 | 
			
		||||
    (with respect to the roots) is dead.</para></listitem>
 | 
			
		||||
    set of “dead” store paths, which is just the opposite of the set
 | 
			
		||||
    of live paths: any path in the store that is not live (with
 | 
			
		||||
    respect to the roots) is dead.</para></listitem>
 | 
			
		||||
    
 | 
			
		||||
  </varlistentry>
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -447,7 +447,8 @@ following:
 | 
			
		|||
(import pkgs/system/i686-linux.nix).hello</programlisting>
 | 
			
		||||
 | 
			
		||||
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>
 | 
			
		||||
$ nix-build ./test.nix
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
		Loading…
	
	Add table
		Add a link
		
	
		Reference in a new issue