<envar> -> <literal>
This commit is contained in:
Eelco Dolstra
parent
942cd687f9
commit
c20c082383
33 changed files with 111 additions and 111 deletions
|
|
@ -31,13 +31,13 @@ they are, how they interact, and their configuration trade-offs.</para>
|
|||
</variablelist>
|
||||
|
||||
<para>The <xref linkend="conf-cores" /> setting determines the value of
|
||||
<envar>NIX_BUILD_CORES</envar>. <envar>NIX_BUILD_CORES</envar> is equal
|
||||
<literal>NIX_BUILD_CORES</literal>. <literal>NIX_BUILD_CORES</literal> is equal
|
||||
to <xref linkend="conf-cores" />, unless <xref linkend="conf-cores" />
|
||||
equals <literal>0</literal>, in which case <envar>NIX_BUILD_CORES</envar>
|
||||
equals <literal>0</literal>, in which case <literal>NIX_BUILD_CORES</literal>
|
||||
will be the total number of cores in the system.</para>
|
||||
|
||||
<para>The maximum number of consumed cores is a simple multiplication,
|
||||
<xref linkend="conf-max-jobs" /> * <envar>NIX_BUILD_CORES</envar>.</para>
|
||||
<xref linkend="conf-max-jobs" /> * <literal>NIX_BUILD_CORES</literal>.</para>
|
||||
|
||||
<para>The balance on how to set these two independent variables depends
|
||||
upon each builder's workload and hardware. Here are a few example
|
||||
|
|
@ -49,7 +49,7 @@ scenarios on a machine with 24 cores:</para>
|
|||
<tr>
|
||||
<th><xref linkend="conf-max-jobs" /></th>
|
||||
<th><xref linkend="conf-cores" /></th>
|
||||
<th><envar>NIX_BUILD_CORES</envar></th>
|
||||
<th><literal>NIX_BUILD_CORES</literal></th>
|
||||
<th>Maximum Processes</th>
|
||||
<th>Result</th>
|
||||
</tr>
|
||||
|
|
@ -116,6 +116,6 @@ scenarios on a machine with 24 cores:</para>
|
|||
|
||||
<para>It is up to the derivations' build script to respect
|
||||
host's requested cores-per-build by following the value of the
|
||||
<envar>NIX_BUILD_CORES</envar> environment variable.</para>
|
||||
<literal>NIX_BUILD_CORES</literal> environment variable.</para>
|
||||
|
||||
</chapter>
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ bash: nix-store: command not found
|
|||
error: cannot connect to 'mac'
|
||||
</screen>
|
||||
|
||||
then you need to ensure that the <envar>PATH</envar> of
|
||||
then you need to ensure that the <literal>PATH</literal> of
|
||||
non-interactive login shells contains Nix.</para>
|
||||
|
||||
<warning><para>If you are building via the Nix daemon, it is the Nix
|
||||
|
|
|
|||
|
|
@ -25,20 +25,20 @@
|
|||
<filename><replaceable>sysconfdir</replaceable>/nix/nix.conf</filename>
|
||||
(i.e. <filename>/etc/nix/nix.conf</filename> on most systems), or
|
||||
<filename>$NIX_CONF_DIR/nix.conf</filename> if
|
||||
<envar>NIX_CONF_DIR</envar> is set. Values loaded in this file are not forwarded to the Nix daemon. The
|
||||
<literal>NIX_CONF_DIR</literal> is set. Values loaded in this file are not forwarded to the Nix daemon. The
|
||||
client assumes that the daemon has already loaded them.
|
||||
</para>
|
||||
|
||||
<para>User-specific configuration files:</para>
|
||||
|
||||
<para>
|
||||
If <envar>NIX_USER_CONF_FILES</envar> is set, then each path separated by
|
||||
If <literal>NIX_USER_CONF_FILES</literal> is set, then each path separated by
|
||||
<literal>:</literal> will be loaded in reverse order.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Otherwise it will look for <filename>nix/nix.conf</filename> files in
|
||||
<envar>XDG_CONFIG_DIRS</envar> and <envar>XDG_CONFIG_HOME</envar>.
|
||||
<literal>XDG_CONFIG_DIRS</literal> and <literal>XDG_CONFIG_HOME</literal>.
|
||||
|
||||
The default location is <filename>$HOME/.config/nix.conf</filename> if
|
||||
those environment variables are unset.
|
||||
|
|
@ -195,8 +195,8 @@ false</literal>.</para>
|
|||
|
||||
<para>If the build users group is empty, builds will be performed
|
||||
under the uid of the Nix process (that is, the uid of the caller
|
||||
if <envar>NIX_REMOTE</envar> is empty, the uid under which the Nix
|
||||
daemon runs if <envar>NIX_REMOTE</envar> is
|
||||
if <literal>NIX_REMOTE</literal> is empty, the uid under which the Nix
|
||||
daemon runs if <literal>NIX_REMOTE</literal> is
|
||||
<literal>daemon</literal>). Obviously, this should not be used in
|
||||
multi-user settings with untrusted users.</para>
|
||||
|
||||
|
|
@ -231,7 +231,7 @@ false</literal>.</para>
|
|||
<varlistentry xml:id="conf-cores"><term><literal>cores</literal></term>
|
||||
|
||||
<listitem><para>Sets the value of the
|
||||
<envar>NIX_BUILD_CORES</envar> environment variable in the
|
||||
<literal>NIX_BUILD_CORES</literal> environment variable in the
|
||||
invocation of builders. Builders can use this variable at their
|
||||
discretion to control the maximum amount of parallelism. For
|
||||
instance, in Nixpkgs, if the derivation attribute
|
||||
|
|
@ -694,7 +694,7 @@ password <replaceable>my-password</replaceable>
|
|||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><envar>DRV_PATH</envar></term>
|
||||
<term><literal>DRV_PATH</literal></term>
|
||||
<listitem>
|
||||
<para>The derivation for the built paths.</para>
|
||||
<para>Example:
|
||||
|
|
@ -704,7 +704,7 @@ password <replaceable>my-password</replaceable>
|
|||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>OUT_PATHS</envar></term>
|
||||
<term><literal>OUT_PATHS</literal></term>
|
||||
<listitem>
|
||||
<para>Output paths of the built derivation, separated by a space character.</para>
|
||||
<para>Example:
|
||||
|
|
@ -754,7 +754,7 @@ password <replaceable>my-password</replaceable>
|
|||
|
||||
<para>If set to <literal>true</literal>, the Nix evaluator will
|
||||
not allow access to any files outside of the Nix search path (as
|
||||
set via the <envar>NIX_PATH</envar> environment variable or the
|
||||
set via the <literal>NIX_PATH</literal> environment variable or the
|
||||
<option>-I</option> option), or to URIs outside of
|
||||
<option>allowed-uri</option>. The default is
|
||||
<literal>false</literal>.</para>
|
||||
|
|
@ -958,7 +958,7 @@ requiredSystemFeatures = [ "kvm" ];
|
|||
<para>Nix caches tarballs in
|
||||
<filename>$XDG_CACHE_HOME/nix/tarballs</filename>.</para>
|
||||
|
||||
<para>Files fetched via <envar>NIX_PATH</envar>,
|
||||
<para>Files fetched via <literal>NIX_PATH</literal>,
|
||||
<function>fetchGit</function>, <function>fetchMercurial</function>,
|
||||
<function>fetchTarball</function>, and <function>fetchurl</function>
|
||||
respect this TTL.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@
|
|||
|
||||
<variablelist xml:id="env-common">
|
||||
|
||||
<varlistentry><term><envar>IN_NIX_SHELL</envar></term>
|
||||
<varlistentry><term><literal>IN_NIX_SHELL</literal></term>
|
||||
|
||||
<listitem><para>Indicator that tells if the current environment was set up by
|
||||
<command>nix-shell</command>. Since Nix 2.0 the values are
|
||||
|
|
@ -19,7 +19,7 @@
|
|||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry xml:id="env-NIX_PATH"><term><envar>NIX_PATH</envar></term>
|
||||
<varlistentry xml:id="env-NIX_PATH"><term><literal>NIX_PATH</literal></term>
|
||||
|
||||
<listitem>
|
||||
|
||||
|
|
@ -50,7 +50,7 @@ nixpkgs=/home/eelco/Dev/nixpkgs-branch:/etc/nixos</screen>
|
|||
interpreted as the URL of a tarball that will be downloaded and
|
||||
unpacked to a temporary location. The tarball must consist of a
|
||||
single top-level directory. For example, setting
|
||||
<envar>NIX_PATH</envar> to
|
||||
<literal>NIX_PATH</literal> to
|
||||
|
||||
<screen>
|
||||
nixpkgs=https://github.com/NixOS/nixpkgs/archive/nixos-15.09.tar.gz</screen>
|
||||
|
|
@ -65,12 +65,12 @@ nixpkgs=https://github.com/NixOS/nixpkgs/archive/nixos-15.09.tar.gz</screen>
|
|||
|
||||
<para>The search path can be extended using the <option
|
||||
linkend="opt-I">-I</option> option, which takes precedence over
|
||||
<envar>NIX_PATH</envar>.</para></listitem>
|
||||
<literal>NIX_PATH</literal>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><envar>NIX_IGNORE_SYMLINK_STORE</envar></term>
|
||||
<varlistentry><term><literal>NIX_IGNORE_SYMLINK_STORE</literal></term>
|
||||
|
||||
<listitem>
|
||||
|
||||
|
|
@ -84,7 +84,7 @@ nixpkgs=https://github.com/NixOS/nixpkgs/archive/nixos-15.09.tar.gz</screen>
|
|||
except when builds are deployed to machines where
|
||||
<filename>/nix/store</filename> resolves differently. If you are
|
||||
sure that you’re not going to do that, you can set
|
||||
<envar>NIX_IGNORE_SYMLINK_STORE</envar> to <envar>1</envar>.</para>
|
||||
<literal>NIX_IGNORE_SYMLINK_STORE</literal> to <literal>1</literal>.</para>
|
||||
|
||||
<para>Note that if you’re symlinking the Nix store so that you can
|
||||
put it on another file system than the root file system, on Linux
|
||||
|
|
@ -102,7 +102,7 @@ $ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
|||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><envar>NIX_STORE_DIR</envar></term>
|
||||
<varlistentry><term><literal>NIX_STORE_DIR</literal></term>
|
||||
|
||||
<listitem><para>Overrides the location of the Nix store (default
|
||||
<filename><replaceable>prefix</replaceable>/store</filename>).</para></listitem>
|
||||
|
|
@ -110,7 +110,7 @@ $ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
|||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><envar>NIX_DATA_DIR</envar></term>
|
||||
<varlistentry><term><literal>NIX_DATA_DIR</literal></term>
|
||||
|
||||
<listitem><para>Overrides the location of the Nix static data
|
||||
directory (default
|
||||
|
|
@ -119,7 +119,7 @@ $ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
|||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><envar>NIX_LOG_DIR</envar></term>
|
||||
<varlistentry><term><literal>NIX_LOG_DIR</literal></term>
|
||||
|
||||
<listitem><para>Overrides the location of the Nix log directory
|
||||
(default <filename><replaceable>prefix</replaceable>/var/log/nix</filename>).</para></listitem>
|
||||
|
|
@ -127,7 +127,7 @@ $ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
|||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><envar>NIX_STATE_DIR</envar></term>
|
||||
<varlistentry><term><literal>NIX_STATE_DIR</literal></term>
|
||||
|
||||
<listitem><para>Overrides the location of the Nix state directory
|
||||
(default <filename><replaceable>prefix</replaceable>/var/nix</filename>).</para></listitem>
|
||||
|
|
@ -135,7 +135,7 @@ $ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
|||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><envar>NIX_CONF_DIR</envar></term>
|
||||
<varlistentry><term><literal>NIX_CONF_DIR</literal></term>
|
||||
|
||||
<listitem><para>Overrides the location of the system Nix configuration
|
||||
directory (default
|
||||
|
|
@ -143,7 +143,7 @@ $ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
|||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><envar>NIX_USER_CONF_FILES</envar></term>
|
||||
<varlistentry><term><literal>NIX_USER_CONF_FILES</literal></term>
|
||||
|
||||
<listitem><para>Overrides the location of the user Nix configuration files
|
||||
to load from (defaults to the XDG spec locations). The variable is treated
|
||||
|
|
@ -151,7 +151,7 @@ $ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
|||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><envar>TMPDIR</envar></term>
|
||||
<varlistentry><term><literal>TMPDIR</literal></term>
|
||||
|
||||
<listitem><para>Use the specified directory to store temporary
|
||||
files. In particular, this includes temporary build directories;
|
||||
|
|
@ -161,7 +161,7 @@ $ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
|||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry xml:id="envar-remote"><term><envar>NIX_REMOTE</envar></term>
|
||||
<varlistentry xml:id="envar-remote"><term><literal>NIX_REMOTE</literal></term>
|
||||
|
||||
<listitem><para>This variable should be set to
|
||||
<literal>daemon</literal> if you want to use the Nix daemon to
|
||||
|
|
@ -174,7 +174,7 @@ $ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
|||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><envar>NIX_SHOW_STATS</envar></term>
|
||||
<varlistentry><term><literal>NIX_SHOW_STATS</literal></term>
|
||||
|
||||
<listitem><para>If set to <literal>1</literal>, Nix will print some
|
||||
evaluation statistics, such as the number of values
|
||||
|
|
@ -183,7 +183,7 @@ $ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
|||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><envar>NIX_COUNT_CALLS</envar></term>
|
||||
<varlistentry><term><literal>NIX_COUNT_CALLS</literal></term>
|
||||
|
||||
<listitem><para>If set to <literal>1</literal>, Nix will print how
|
||||
often functions were called during Nix expression evaluation. This
|
||||
|
|
@ -192,7 +192,7 @@ $ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
|||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><envar>GC_INITIAL_HEAP_SIZE</envar></term>
|
||||
<varlistentry><term><literal>GC_INITIAL_HEAP_SIZE</literal></term>
|
||||
|
||||
<listitem><para>If Nix has been configured to use the Boehm garbage
|
||||
collector, this variable sets the initial size of the heap in bytes.
|
||||
|
|
|
|||
|
|
@ -129,7 +129,7 @@ those paths. If this bothers you, use
|
|||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><envar>NIX_SSHOPTS</envar></term>
|
||||
<varlistentry><term><literal>NIX_SSHOPTS</literal></term>
|
||||
|
||||
<listitem><para>Additional options to be passed to
|
||||
<command>ssh</command> on the command line.</para></listitem>
|
||||
|
|
|
|||
|
|
@ -277,7 +277,7 @@ also <xref linkend="sec-common-options" />.</phrase></para>
|
|||
<listitem><para>A symbolic link to the user's current profile. By
|
||||
default, this symlink points to
|
||||
<filename><replaceable>prefix</replaceable>/var/nix/profiles/default</filename>.
|
||||
The <envar>PATH</envar> environment variable should include
|
||||
The <literal>PATH</literal> environment variable should include
|
||||
<filename>~/.nix-profile/bin</filename> for the user environment
|
||||
to be visible to the user.</para></listitem>
|
||||
|
||||
|
|
@ -1485,7 +1485,7 @@ error: no generation older than the current (91) exists</screen>
|
|||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><envar>NIX_PROFILE</envar></term>
|
||||
<varlistentry><term><literal>NIX_PROFILE</literal></term>
|
||||
|
||||
<listitem><para>Location of the Nix profile. Defaults to the
|
||||
target of the symlink <filename>~/.nix-profile</filename>, if it
|
||||
|
|
|
|||
|
|
@ -106,10 +106,10 @@ input.</para>
|
|||
<varlistentry><term><option>--find-file</option></term>
|
||||
|
||||
<listitem><para>Look up the given files in Nix’s search path (as
|
||||
specified by the <envar linkend="env-NIX_PATH">NIX_PATH</envar>
|
||||
specified by the <envar linkend="env-NIX_PATH">NIX_PATH</literal>
|
||||
environment variable). If found, print the corresponding absolute
|
||||
paths on standard output. For instance, if
|
||||
<envar>NIX_PATH</envar> is
|
||||
<literal>NIX_PATH</literal> is
|
||||
<literal>nixpkgs=/home/alice/nixpkgs</literal>, then
|
||||
<literal>nix-instantiate --find-file nixpkgs/default.nix</literal>
|
||||
will print
|
||||
|
|
|
|||
|
|
@ -141,8 +141,8 @@ also <xref linkend="sec-common-options" />.</phrase></para>
|
|||
almost entirely cleared before the interactive shell is started,
|
||||
so you get an environment that more closely corresponds to the
|
||||
“real” Nix build. A few variables, in particular
|
||||
<envar>HOME</envar>, <envar>USER</envar> and
|
||||
<envar>DISPLAY</envar>, are retained. Note that
|
||||
<literal>HOME</literal>, <literal>USER</literal> and
|
||||
<literal>DISPLAY</literal>, are retained. Note that
|
||||
<filename>~/.bashrc</filename> and (depending on your Bash
|
||||
installation) <filename>/etc/bashrc</filename> are still sourced,
|
||||
so any variables set there will affect the interactive
|
||||
|
|
@ -193,10 +193,10 @@ also <xref linkend="sec-common-options" />.</phrase></para>
|
|||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><envar>NIX_BUILD_SHELL</envar></term>
|
||||
<varlistentry><term><literal>NIX_BUILD_SHELL</literal></term>
|
||||
|
||||
<listitem><para>Shell used to start the interactive environment.
|
||||
Defaults to the <command>bash</command> found in <envar>PATH</envar>.</para></listitem>
|
||||
Defaults to the <command>bash</command> found in <literal>PATH</literal>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
|
@ -254,7 +254,7 @@ $ nix-shell -p sqlite 'git.override { withManual = false; }'
|
|||
|
||||
The <command>-p</command> flag looks up Nixpkgs in the Nix search
|
||||
path. You can override it by passing <option>-I</option> or setting
|
||||
<envar>NIX_PATH</envar>. For example, the following gives you a shell
|
||||
<literal>NIX_PATH</literal>. For example, the following gives you a shell
|
||||
containing the Pan package from a specific revision of Nixpkgs:
|
||||
|
||||
<screen>
|
||||
|
|
|
|||
|
|
@ -1433,7 +1433,7 @@ loads it into the Nix database.</para>
|
|||
<para>The operation <option>--print-env</option> prints out the
|
||||
environment of a derivation in a format that can be evaluated by a
|
||||
shell. The command line arguments of the builder are placed in the
|
||||
variable <envar>_args</envar>.</para>
|
||||
variable <literal>_args</literal>.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
|
|
|||
|
|
@ -160,7 +160,7 @@
|
|||
|
||||
<varlistentry xml:id="opt-cores"><term><option>--cores</option></term>
|
||||
|
||||
<listitem><para>Sets the value of the <envar>NIX_BUILD_CORES</envar>
|
||||
<listitem><para>Sets the value of the <literal>NIX_BUILD_CORES</literal>
|
||||
environment variable in the invocation of builders. Builders can
|
||||
use this variable at their discretion to control the maximum amount
|
||||
of parallelism. For instance, in Nixpkgs, if the derivation
|
||||
|
|
@ -370,10 +370,10 @@
|
|||
|
||||
<listitem><para>Add a path to the Nix expression search path. This
|
||||
option may be given multiple times. See the <envar
|
||||
linkend="env-NIX_PATH">NIX_PATH</envar> environment variable for
|
||||
linkend="env-NIX_PATH">NIX_PATH</literal> environment variable for
|
||||
information on the semantics of the Nix search path. Paths added
|
||||
through <option>-I</option> take precedence over
|
||||
<envar>NIX_PATH</envar>.</para></listitem>
|
||||
<literal>NIX_PATH</literal>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
|
|
|||
|
|
@ -139,7 +139,7 @@ impureEnvVars = [ "http_proxy" "https_proxy" <replaceable>...</replaceable> ];
|
|||
</programlisting>
|
||||
|
||||
to make it use the proxy server configuration specified by the
|
||||
user in the environment variables <envar>http_proxy</envar> and
|
||||
user in the environment variables <literal>http_proxy</literal> and
|
||||
friends.</para>
|
||||
|
||||
<para>This attribute is only allowed in <link
|
||||
|
|
@ -294,12 +294,12 @@ big = "a very long string";
|
|||
</programlisting>
|
||||
|
||||
then when the builder runs, the environment variable
|
||||
<envar>bigPath</envar> will contain the absolute path to a
|
||||
<literal>bigPath</literal> will contain the absolute path to a
|
||||
temporary file containing <literal>a very long
|
||||
string</literal>. That is, for any attribute
|
||||
<replaceable>x</replaceable> listed in
|
||||
<varname>passAsFile</varname>, Nix will pass an environment
|
||||
variable <envar><replaceable>x</replaceable>Path</envar> holding
|
||||
variable <literal><replaceable>x</replaceable>Path</literal> holding
|
||||
the path of the file containing the value of attribute
|
||||
<replaceable>x</replaceable>. This is useful when you need to pass
|
||||
large strings to a builder, since most operating systems impose a
|
||||
|
|
|
|||
|
|
@ -35,19 +35,19 @@ steps:</para>
|
|||
|
||||
<para>When Nix runs a builder, it initially completely clears the
|
||||
environment (except for the attributes declared in the
|
||||
derivation). For instance, the <envar>PATH</envar> variable is
|
||||
derivation). For instance, the <literal>PATH</literal> variable is
|
||||
empty<footnote><para>Actually, it's initialised to
|
||||
<filename>/path-not-set</filename> to prevent Bash from setting it
|
||||
to a default value.</para></footnote>. This is done to prevent
|
||||
undeclared inputs from being used in the build process. If for
|
||||
example the <envar>PATH</envar> contained
|
||||
example the <literal>PATH</literal> contained
|
||||
<filename>/usr/bin</filename>, then you might accidentally use
|
||||
<filename>/usr/bin/gcc</filename>.</para>
|
||||
|
||||
<para>So the first step is to set up the environment. This is
|
||||
done by calling the <filename>setup</filename> script of the
|
||||
standard environment. The environment variable
|
||||
<envar>stdenv</envar> points to the location of the standard
|
||||
<literal>stdenv</literal> points to the location of the standard
|
||||
environment being used. (It wasn't specified explicitly as an
|
||||
attribute in <xref linkend='ex-hello-nix' />, but
|
||||
<varname>mkDerivation</varname> adds it automatically.)</para>
|
||||
|
|
@ -57,7 +57,7 @@ steps:</para>
|
|||
<callout arearefs='ex-hello-builder-co-2'>
|
||||
|
||||
<para>Since Hello needs Perl, we have to make sure that Perl is in
|
||||
the <envar>PATH</envar>. The <envar>perl</envar> environment
|
||||
the <literal>PATH</literal>. The <literal>perl</literal> environment
|
||||
variable points to the location of the Perl package (since it
|
||||
was passed in as an attribute to the derivation), so
|
||||
<filename><replaceable>$perl</replaceable>/bin</filename> is the
|
||||
|
|
@ -70,7 +70,7 @@ steps:</para>
|
|||
<para>Now we have to unpack the sources. The
|
||||
<varname>src</varname> attribute was bound to the result of
|
||||
fetching the Hello source tarball from the network, so the
|
||||
<envar>src</envar> environment variable points to the location in
|
||||
<literal>src</literal> environment variable points to the location in
|
||||
the Nix store to which the tarball was downloaded. After
|
||||
unpacking, we <command>cd</command> to the resulting source
|
||||
directory.</para>
|
||||
|
|
@ -93,7 +93,7 @@ steps:</para>
|
|||
<filename>/nix/store/9a54ba97fb71b65fda531012d0443ce2-hello-2.1.1</filename>.
|
||||
Nix computes this path by cryptographically hashing all attributes
|
||||
of the derivation. The path is passed to the builder through the
|
||||
<envar>out</envar> environment variable. So here we give
|
||||
<literal>out</literal> environment variable. So here we give
|
||||
<filename>configure</filename> the parameter
|
||||
<literal>--prefix=$out</literal> to cause Hello to be installed in
|
||||
the expected location.</para>
|
||||
|
|
@ -103,7 +103,7 @@ steps:</para>
|
|||
<callout arearefs='ex-hello-builder-co-5'>
|
||||
|
||||
<para>Finally we build Hello (<literal>make</literal>) and install
|
||||
it into the location specified by <envar>out</envar>
|
||||
it into the location specified by <literal>out</literal>
|
||||
(<literal>make install</literal>).</para>
|
||||
|
||||
</callout>
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ the Nixpkgs manual for details.</para>
|
|||
<itemizedlist>
|
||||
|
||||
<listitem><para>A temporary directory is created under the directory
|
||||
specified by <envar>TMPDIR</envar> (default
|
||||
specified by <literal>TMPDIR</literal> (default
|
||||
<filename>/tmp</filename>) where the build will take place. The
|
||||
current directory is changed to this directory.</para></listitem>
|
||||
|
||||
|
|
@ -133,29 +133,29 @@ the Nixpkgs manual for details.</para>
|
|||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para><envar>NIX_BUILD_TOP</envar> contains the path of
|
||||
<listitem><para><literal>NIX_BUILD_TOP</literal> contains the path of
|
||||
the temporary directory for this build.</para></listitem>
|
||||
|
||||
<listitem><para>Also, <envar>TMPDIR</envar>,
|
||||
<envar>TEMPDIR</envar>, <envar>TMP</envar>, <envar>TEMP</envar>
|
||||
<listitem><para>Also, <literal>TMPDIR</literal>,
|
||||
<literal>TEMPDIR</literal>, <literal>TMP</literal>, <literal>TEMP</literal>
|
||||
are set to point to the temporary directory. This is to prevent
|
||||
the builder from accidentally writing temporary files anywhere
|
||||
else. Doing so might cause interference by other
|
||||
processes.</para></listitem>
|
||||
|
||||
<listitem><para><envar>PATH</envar> is set to
|
||||
<listitem><para><literal>PATH</literal> is set to
|
||||
<filename>/path-not-set</filename> to prevent shells from
|
||||
initialising it to their built-in default value.</para></listitem>
|
||||
|
||||
<listitem><para><envar>HOME</envar> is set to
|
||||
<listitem><para><literal>HOME</literal> is set to
|
||||
<filename>/homeless-shelter</filename> to prevent programs from
|
||||
using <filename>/etc/passwd</filename> or the like to find the
|
||||
user's home directory, which could cause impurity. Usually, when
|
||||
<envar>HOME</envar> is set, it is used as the location of the home
|
||||
<literal>HOME</literal> is set, it is used as the location of the home
|
||||
directory, even if it points to a non-existent
|
||||
path.</para></listitem>
|
||||
|
||||
<listitem><para><envar>NIX_STORE</envar> is set to the path of the
|
||||
<listitem><para><literal>NIX_STORE</literal> is set to the path of the
|
||||
top-level Nix store directory (typically,
|
||||
<filename>/nix/store</filename>).</para></listitem>
|
||||
|
||||
|
|
|
|||
|
|
@ -38,18 +38,18 @@ genericBuild <co xml:id='ex-hello-builder2-co-3' /></programlisting>
|
|||
|
||||
<callout arearefs='ex-hello-builder2-co-1'>
|
||||
|
||||
<para>The <envar>buildInputs</envar> variable tells
|
||||
<para>The <literal>buildInputs</literal> variable tells
|
||||
<filename>setup</filename> to use the indicated packages as
|
||||
<quote>inputs</quote>. This means that if a package provides a
|
||||
<filename>bin</filename> subdirectory, it's added to
|
||||
<envar>PATH</envar>; if it has a <filename>include</filename>
|
||||
<literal>PATH</literal>; if it has a <filename>include</filename>
|
||||
subdirectory, it's added to GCC's header search path; and so
|
||||
on.<footnote><para>How does it work? <filename>setup</filename>
|
||||
tries to source the file
|
||||
<filename><replaceable>pkg</replaceable>/nix-support/setup-hook</filename>
|
||||
of all dependencies. These “setup hooks” can then set up whatever
|
||||
environment variables they want; for instance, the setup hook for
|
||||
Perl sets the <envar>PERL5LIB</envar> environment variable to
|
||||
Perl sets the <literal>PERL5LIB</literal> environment variable to
|
||||
contain the <filename>lib/site_perl</filename> directories of all
|
||||
inputs.</para></footnote>
|
||||
</para>
|
||||
|
|
@ -78,7 +78,7 @@ genericBuild <co xml:id='ex-hello-builder2-co-3' /></programlisting>
|
|||
</calloutlist>
|
||||
|
||||
<para>Discerning readers will note that the
|
||||
<envar>buildInputs</envar> could just as well have been set in the Nix
|
||||
<literal>buildInputs</literal> could just as well have been set in the Nix
|
||||
expression, like this:
|
||||
|
||||
<programlisting>
|
||||
|
|
|
|||
|
|
@ -176,7 +176,7 @@ stdenv.mkDerivation {
|
|||
<para>Paths can also be specified between angle brackets, e.g.
|
||||
<literal><nixpkgs></literal>. This means that the directories
|
||||
listed in the environment variable
|
||||
<envar linkend="env-NIX_PATH">NIX_PATH</envar> will be searched
|
||||
<envar linkend="env-NIX_PATH">NIX_PATH</literal> will be searched
|
||||
for the given file or directory name.
|
||||
</para>
|
||||
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ name.</para>
|
|||
|
||||
<para>Nix has transactional semantics. Once a build finishes
|
||||
successfully, Nix makes a note of this in its database: it registers
|
||||
that the path denoted by <envar>out</envar> is now
|
||||
that the path denoted by <literal>out</literal> is now
|
||||
<quote>valid</quote>. If you try to build the derivation again, Nix
|
||||
will see that the path is already valid and finish immediately. If a
|
||||
build fails, either because it returns a non-zero exit code, because
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
<title>Environment Variables</title>
|
||||
|
||||
<para>To use Nix, some environment variables should be set. In
|
||||
particular, <envar>PATH</envar> should contain the directories
|
||||
particular, <literal>PATH</literal> should contain the directories
|
||||
<filename><replaceable>prefix</replaceable>/bin</filename> and
|
||||
<filename>~/.nix-profile/bin</filename>. The first directory contains
|
||||
the Nix tools themselves, while <filename>~/.nix-profile</filename> is
|
||||
|
|
@ -23,15 +23,15 @@ source <replaceable>prefix</replaceable>/etc/profile.d/nix.sh</screen>
|
|||
|
||||
<section xml:id="sec-nix-ssl-cert-file">
|
||||
|
||||
<title><envar>NIX_SSL_CERT_FILE</envar></title>
|
||||
<title><literal>NIX_SSL_CERT_FILE</literal></title>
|
||||
|
||||
<para>If you need to specify a custom certificate bundle to account
|
||||
for an HTTPS-intercepting man in the middle proxy, you must specify
|
||||
the path to the certificate bundle in the environment variable
|
||||
<envar>NIX_SSL_CERT_FILE</envar>.</para>
|
||||
<literal>NIX_SSL_CERT_FILE</literal>.</para>
|
||||
|
||||
|
||||
<para>If you don't specify a <envar>NIX_SSL_CERT_FILE</envar>
|
||||
<para>If you don't specify a <literal>NIX_SSL_CERT_FILE</literal>
|
||||
manually, Nix will install and use its own certificate
|
||||
bundle.</para>
|
||||
|
||||
|
|
@ -56,7 +56,7 @@ the Nix installer will detect the presense of Nix configuration, and
|
|||
abort.</para></note>
|
||||
|
||||
<section xml:id="sec-nix-ssl-cert-file-with-nix-daemon-and-macos">
|
||||
<title><envar>NIX_SSL_CERT_FILE</envar> with macOS and the Nix daemon</title>
|
||||
<title><literal>NIX_SSL_CERT_FILE</literal> with macOS and the Nix daemon</title>
|
||||
|
||||
<para>On macOS you must specify the environment variable for the Nix
|
||||
daemon service, then restart it:</para>
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ The install script will modify the first writable file from amongst
|
|||
<filename>.bash_profile</filename>, <filename>.bash_login</filename>
|
||||
and <filename>.profile</filename> to source
|
||||
<filename>~/.nix-profile/etc/profile.d/nix.sh</filename>. You can set
|
||||
the <envar>NIX_INSTALLER_NO_MODIFY_PROFILE</envar> environment
|
||||
the <literal>NIX_INSTALLER_NO_MODIFY_PROFILE</literal> environment
|
||||
variable before executing the install script to disable this
|
||||
behaviour.
|
||||
</para>
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ You’ll want to put that line somewhere in your system’s boot
|
|||
scripts.</para>
|
||||
|
||||
<para>To let unprivileged users use the daemon, they should set the
|
||||
<link linkend="envar-remote"><envar>NIX_REMOTE</envar> environment
|
||||
<link linkend="envar-remote"><literal>NIX_REMOTE</literal> environment
|
||||
variable</link> to <literal>daemon</literal>. So you should put a
|
||||
line like
|
||||
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ extremely well.</para>
|
|||
<para>Nix has multi-user support. This means that non-privileged
|
||||
users can securely install software. Each user can have a different
|
||||
<emphasis>profile</emphasis>, a set of packages in the Nix store that
|
||||
appear in the user’s <envar>PATH</envar>. If a user installs a
|
||||
appear in the user’s <literal>PATH</literal>. If a user installs a
|
||||
package that another user has already installed previously, the
|
||||
package won’t be built or downloaded a second time. At the same time,
|
||||
it is not possible for one user to inject a Trojan horse into a
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ on the set of installed applications. That is, there might be lots of
|
|||
applications present on the system (possibly in many different
|
||||
versions), but users can have a specific selection of those active —
|
||||
where “active” just means that it appears in a directory
|
||||
in the user’s <envar>PATH</envar>. Such a view on the set of
|
||||
in the user’s <literal>PATH</literal>. Such a view on the set of
|
||||
installed applications is called a <emphasis>user
|
||||
environment</emphasis>, which is just a directory tree consisting of
|
||||
symlinks to the files of the active applications. </para>
|
||||
|
|
|
|||
|
|
@ -41,9 +41,9 @@ store.</para>
|
|||
$ /nix/store/dpmvp969yhdq...-subversion-1.1.3/bin/svn</screen>
|
||||
|
||||
every time you want to run Subversion. Of course we could set up the
|
||||
<envar>PATH</envar> environment variable to include the
|
||||
<literal>PATH</literal> environment variable to include the
|
||||
<filename>bin</filename> directory of every package we want to use,
|
||||
but this is not very convenient since changing <envar>PATH</envar>
|
||||
but this is not very convenient since changing <literal>PATH</literal>
|
||||
doesn’t take effect for already existing processes. The solution Nix
|
||||
uses is to create directory trees of symlinks to
|
||||
<emphasis>activated</emphasis> packages. These are called
|
||||
|
|
@ -122,10 +122,10 @@ $ nix-env --list-generations</screen></para>
|
|||
|
||||
<para>You generally wouldn’t have
|
||||
<filename>/nix/var/nix/profiles/<replaceable>some-profile</replaceable>/bin</filename>
|
||||
in your <envar>PATH</envar>. Rather, there is a symlink
|
||||
in your <literal>PATH</literal>. Rather, there is a symlink
|
||||
<filename>~/.nix-profile</filename> that points to your current
|
||||
profile. This means that you should put
|
||||
<filename>~/.nix-profile/bin</filename> in your <envar>PATH</envar>
|
||||
<filename>~/.nix-profile/bin</filename> in your <literal>PATH</literal>
|
||||
(and indeed, that’s what the initialisation script
|
||||
<filename>/nix/etc/profile.d/nix.sh</filename> does). This makes it
|
||||
easier to switch to a different profile. You can do that using the
|
||||
|
|
|
|||
|
|
@ -184,9 +184,9 @@ irreversible.</para></warning>
|
|||
|
||||
|
||||
<listitem><para>Nix now works behind an HTTP proxy server; just set
|
||||
the standard environment variables <envar>http_proxy</envar>,
|
||||
<envar>https_proxy</envar>, <envar>ftp_proxy</envar> or
|
||||
<envar>all_proxy</envar> appropriately. Functions such as
|
||||
the standard environment variables <literal>http_proxy</literal>,
|
||||
<literal>https_proxy</literal>, <literal>ftp_proxy</literal> or
|
||||
<literal>all_proxy</literal> appropriately. Functions such as
|
||||
<function>fetchurl</function> in Nixpkgs also respect these
|
||||
variables.</para></listitem>
|
||||
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ $ rm __db* log.* derivers references referrers reserved validpaths DB_CONFIG</sc
|
|||
filesystem. For instance, you can speed up an installation by
|
||||
mounting some remote Nix store that already has the packages in
|
||||
question via NFS or <literal>sshfs</literal>. The environment
|
||||
variable <envar>NIX_OTHER_STORES</envar> specifies the locations of
|
||||
variable <literal>NIX_OTHER_STORES</literal> specifies the locations of
|
||||
the remote Nix directories,
|
||||
e.g. <literal>/mnt/remote-fs/nix</literal>.</para></listitem>
|
||||
|
||||
|
|
@ -156,7 +156,7 @@ the following paths will be downloaded/copied (30.02 MiB):
|
|||
|
||||
<listitem><para><command>nix-prefetch-url</command> now supports
|
||||
<literal>mirror://</literal> URLs, provided that the environment
|
||||
variable <envar>NIXPKGS_ALL</envar> points at a Nixpkgs
|
||||
variable <literal>NIXPKGS_ALL</literal> points at a Nixpkgs
|
||||
tree.</para></listitem>
|
||||
|
||||
<listitem><para>Removed the commands
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@
|
|||
<replaceable>N</replaceable></option> as well as a configuration
|
||||
setting <varname>build-cores =
|
||||
<replaceable>N</replaceable></varname> that causes the
|
||||
environment variable <envar>NIX_BUILD_CORES</envar> to be set to
|
||||
environment variable <literal>NIX_BUILD_CORES</literal> to be set to
|
||||
<replaceable>N</replaceable> when the builder is invoked. The
|
||||
builder can use this at its discretion to perform a parallel
|
||||
build, e.g., by calling <command>make -j
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ previous release. Here are the most significant:</para>
|
|||
|
||||
<listitem>
|
||||
<para>Nix now has an search path for expressions. The search path
|
||||
is set using the environment variable <envar>NIX_PATH</envar> and
|
||||
is set using the environment variable <literal>NIX_PATH</literal> and
|
||||
the <option>-I</option> command line option. In Nix expressions,
|
||||
paths between angle brackets are used to specify files that must
|
||||
be looked up in the search path. For instance, the expression
|
||||
|
|
|
|||
|
|
@ -116,7 +116,7 @@ $ mount -o remount,ro,bind /nix/store
|
|||
|
||||
<listitem>
|
||||
<para>Basic Nix expression evaluation profiling: setting the
|
||||
environment variable <envar>NIX_COUNT_CALLS</envar> to
|
||||
environment variable <literal>NIX_COUNT_CALLS</literal> to
|
||||
<literal>1</literal> will cause Nix to print how many times each
|
||||
primop or function was executed.</para>
|
||||
</listitem>
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ features:</para>
|
|||
|
||||
<listitem>
|
||||
<para><command>nix-shell</command> now sets the shell prompt
|
||||
(<envar>PS1</envar>) to ensure that Nix shells are distinguishable
|
||||
(<literal>PS1</literal>) to ensure that Nix shells are distinguishable
|
||||
from your regular shells.</para>
|
||||
</listitem>
|
||||
|
||||
|
|
|
|||
|
|
@ -105,7 +105,7 @@ $ nix-store -l $(which xterm)
|
|||
some terminals show them anyway.</para></listitem>
|
||||
|
||||
<listitem><para>Various commands now automatically pipe their output
|
||||
into the pager as specified by the <envar>PAGER</envar> environment
|
||||
into the pager as specified by the <literal>PAGER</literal> environment
|
||||
variable.</para></listitem>
|
||||
|
||||
<listitem><para>Several improvements to reduce memory consumption in
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ $ nix-build https://github.com/NixOS/nixpkgs/archive/master.tar.gz -A hello
|
|||
master branch.</para></listitem>
|
||||
|
||||
<listitem><para>In the Nix search path (as specified via
|
||||
<envar>NIX_PATH</envar> or <option>-I</option>). For example, to
|
||||
<literal>NIX_PATH</literal> or <option>-I</option>). For example, to
|
||||
start a shell containing the Pan package from a specific version
|
||||
of Nixpkgs:
|
||||
|
||||
|
|
@ -190,8 +190,8 @@ main = do
|
|||
“generation” symlink in <filename>/nix/var/nix/profiles</filename>
|
||||
if something actually changed.</para></listitem>
|
||||
|
||||
<listitem><para>The environment variable <envar>NIX_PAGER</envar>
|
||||
can now be set to override <envar>PAGER</envar>. You can set it to
|
||||
<listitem><para>The environment variable <literal>NIX_PAGER</literal>
|
||||
can now be set to override <literal>PAGER</literal>. You can set it to
|
||||
<literal>cat</literal> to disable paging for Nix commands
|
||||
only.</para></listitem>
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@
|
|||
<listitem>
|
||||
<para>The “copy from other stores” substituter mechanism
|
||||
(<command>copy-from-other-stores</command> and the
|
||||
<envar>NIX_OTHER_STORES</envar> environment variable) has been
|
||||
<literal>NIX_OTHER_STORES</literal> environment variable) has been
|
||||
removed. It was primarily used by the NixOS installer to copy
|
||||
available paths from the installation medium. The replacement is
|
||||
to use a chroot store as a substituter
|
||||
|
|
@ -371,7 +371,7 @@
|
|||
daemon. You can use <literal>auto</literal> or the empty
|
||||
string to auto-select a local or daemon store depending on
|
||||
whether you have write permission to the Nix store. It is no
|
||||
longer necessary to set the <envar>NIX_REMOTE</envar>
|
||||
longer necessary to set the <literal>NIX_REMOTE</literal>
|
||||
environment variable to use the Nix daemon.</para>
|
||||
|
||||
<para>As noted above, <classname>LocalStore</classname> now
|
||||
|
|
@ -492,7 +492,7 @@
|
|||
use <filename>/build</filename> instead of
|
||||
<filename>/tmp</filename> as the temporary build
|
||||
directory. This fixes potential security problems when a build
|
||||
accidentally stores its <envar>TMPDIR</envar> in some
|
||||
accidentally stores its <literal>TMPDIR</literal> in some
|
||||
security-sensitive place, such as an RPATH.</para>
|
||||
</listitem>
|
||||
|
||||
|
|
@ -546,8 +546,8 @@
|
|||
are not using the Nix daemon, you can now just specify a remote
|
||||
build machine on the command line, e.g. <literal>--option builders
|
||||
'ssh://my-mac x86_64-darwin'</literal>. The environment variable
|
||||
<envar>NIX_BUILD_HOOK</envar> has been removed and is no longer
|
||||
needed. The environment variable <envar>NIX_REMOTE_SYSTEMS</envar>
|
||||
<literal>NIX_BUILD_HOOK</literal> has been removed and is no longer
|
||||
needed. The environment variable <literal>NIX_REMOTE_SYSTEMS</literal>
|
||||
is still supported for compatibility, but it is also possible to
|
||||
specify builders in <command>nix.conf</command> by setting the
|
||||
option <literal>builders =
|
||||
|
|
@ -574,7 +574,7 @@
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><envar>NIX_PATH</envar> is now lazy, so URIs in the path are
|
||||
<para><literal>NIX_PATH</literal> is now lazy, so URIs in the path are
|
||||
only downloaded if they are needed for evaluation.</para>
|
||||
</listitem>
|
||||
|
||||
|
|
@ -672,7 +672,7 @@
|
|||
<para><command>nix-shell</command> now uses
|
||||
<varname>bashInteractive</varname> from Nixpkgs, rather than the
|
||||
<command>bash</command> command that happens to be in the caller’s
|
||||
<envar>PATH</envar>. This is especially important on macOS where
|
||||
<literal>PATH</literal>. This is especially important on macOS where
|
||||
the <command>bash</command> provided by the system is seriously
|
||||
outdated and cannot execute <literal>stdenv</literal>’s setup
|
||||
script.</para>
|
||||
|
|
@ -720,7 +720,7 @@
|
|||
configureFlags = "--prefix=${placeholder "out"} --includedir=${placeholder "dev"}";
|
||||
</programlisting>
|
||||
|
||||
will cause the <envar>configureFlags</envar> environment variable
|
||||
will cause the <literal>configureFlags</literal> environment variable
|
||||
to contain the actual store paths corresponding to the
|
||||
<literal>out</literal> and <literal>dev</literal> outputs.</para>
|
||||
</listitem>
|
||||
|
|
@ -815,7 +815,7 @@ configureFlags = "--prefix=${placeholder "out"} --includedir=${placeholder "dev"
|
|||
<varname>__structuredAttrs</varname> is set to
|
||||
<literal>true</literal>, the other derivation attributes are
|
||||
serialised in JSON format and made available to the builder via
|
||||
the file <envar>.attrs.json</envar> in the builder’s temporary
|
||||
the file <literal>.attrs.json</literal> in the builder’s temporary
|
||||
directory. This obviates the need for
|
||||
<varname>passAsFile</varname> since JSON files have no size
|
||||
restrictions, unlike process environments.</para>
|
||||
|
|
@ -823,7 +823,7 @@ configureFlags = "--prefix=${placeholder "out"} --includedir=${placeholder "dev"
|
|||
<para><link
|
||||
xlink:href="https://github.com/NixOS/nix/commit/2d5b1b24bf70a498e4c0b378704cfdb6471cc699">As
|
||||
a convenience to Bash builders</link>, Nix writes a script named
|
||||
<envar>.attrs.sh</envar> to the builder’s directory that
|
||||
<literal>.attrs.sh</literal> to the builder’s directory that
|
||||
initialises shell variables corresponding to all attributes that
|
||||
are representable in Bash. This includes non-nested (associative)
|
||||
arrays. For example, the attribute <literal>hardening.format =
|
||||
|
|
@ -835,7 +835,7 @@ configureFlags = "--prefix=${placeholder "out"} --includedir=${placeholder "dev"
|
|||
<para>Builders can <link
|
||||
xlink:href="https://github.com/NixOS/nix/commit/88e6bb76de5564b3217be9688677d1c89101b2a3">now</link>
|
||||
communicate what build phase they are in by writing messages to
|
||||
the file descriptor specified in <envar>NIX_LOG_FD</envar>. The
|
||||
the file descriptor specified in <literal>NIX_LOG_FD</literal>. The
|
||||
current phase is shown by the <command>nix</command> progress
|
||||
indicator.
|
||||
</para>
|
||||
|
|
|
|||
|
|
@ -114,8 +114,8 @@ import <nix/fetchurl.nix> {
|
|||
|
||||
<listitem>
|
||||
<para>The evaluator now prints profiling statistics (enabled via
|
||||
the <envar>NIX_SHOW_STATS</envar> and
|
||||
<envar>NIX_COUNT_CALLS</envar> environment variables) in JSON
|
||||
the <literal>NIX_SHOW_STATS</literal> and
|
||||
<literal>NIX_COUNT_CALLS</literal> environment variables) in JSON
|
||||
format.</para>
|
||||
</listitem>
|
||||
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ incompatible changes:</para>
|
|||
|
||||
<listitem>
|
||||
<para>Builds are now executed in a pseudo-terminal, and the
|
||||
<envar>TERM</envar> environment variable is set to
|
||||
<literal>TERM</literal> environment variable is set to
|
||||
<literal>xterm-256color</literal>. This allows many programs
|
||||
(e.g. <command>gcc</command>, <command>clang</command>,
|
||||
<command>cmake</command>) to print colorized log output.</para>
|
||||
|
|
|
|||
Loading…
Reference in a new issue