ilyakooo0/nixpkgs
1
0
Fork 0
mirror of https://github.com/ilyakooo0/nixpkgs.git synced 2024-12-26 21:33:03 +03:00
Code Issues Projects Releases Wiki Activity

doc: format the documentation (#57102)

Browse Source
This commit is contained in:
Wael Nasreddine 2019-03-08 21:07:11 -08:00 committed by GitHub
parent b7ebfec61f
commit a7f4fd0014
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
17 changed files with 762 additions and 762 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
doc/.gitignore vendored
View File

@ -1,7 +1,8 @@
*.chapter.xml *.chapter.xml
*.section.xml *.section.xml
.version .version
out functions/library/generated
manual-full.xml
highlightjs
functions/library/locations.xml functions/library/locations.xml
highlightjs
manual-full.xml
out

92
doc/coding-conventions.xml
View File

@ -197,20 +197,14 @@ args.stdenv.mkDerivation (args // {
<title>Package naming</title> <title>Package naming</title>
<para> <para>
The key words The key words <emphasis>must</emphasis>, <emphasis>must not</emphasis>,
<emphasis>must</emphasis>, <emphasis>required</emphasis>, <emphasis>shall</emphasis>, <emphasis>shall
<emphasis>must not</emphasis>, not</emphasis>, <emphasis>should</emphasis>, <emphasis>should
<emphasis>required</emphasis>, not</emphasis>, <emphasis>recommended</emphasis>, <emphasis>may</emphasis>,
<emphasis>shall</emphasis>, and <emphasis>optional</emphasis> in this section are to be interpreted as
<emphasis>shall not</emphasis>, described in <link xlink:href="https://tools.ietf.org/html/rfc2119">RFC
<emphasis>should</emphasis>, 2119</link>. Only <emphasis>emphasized</emphasis> words are to be
<emphasis>should not</emphasis>, interpreted in this way.
<emphasis>recommended</emphasis>,
<emphasis>may</emphasis>,
and <emphasis>optional</emphasis> in this section
are to be interpreted as described in
<link xlink:href="https://tools.ietf.org/html/rfc2119">RFC 2119</link>.
Only <emphasis>emphasized</emphasis> words are to be interpreted in this way.
</para> </para>
<para> <para>
@ -253,8 +247,8 @@ args.stdenv.mkDerivation (args // {
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para> <para>
The <literal>name</literal> attribute <emphasis>should</emphasis> The <literal>name</literal> attribute <emphasis>should</emphasis> be
be identical to the upstream package name. identical to the upstream package name.
</para> </para>
</listitem> </listitem>
<listitem> <listitem>
@ -275,28 +269,29 @@ args.stdenv.mkDerivation (args // {
<para> <para>
If a package is not a release but a commit from a repository, then the If a package is not a release but a commit from a repository, then the
version part of the name <emphasis>must</emphasis> be the date of that version part of the name <emphasis>must</emphasis> be the date of that
(fetched) commit. The date <emphasis>must</emphasis> be in <literal>"YYYY-MM-DD"</literal> (fetched) commit. The date <emphasis>must</emphasis> be in
format. Also append <literal>"unstable"</literal> to the name - e.g., <literal>"YYYY-MM-DD"</literal> format. Also append
<literal>"unstable"</literal> to the name - e.g.,
<literal>"pkgname-unstable-2014-09-23"</literal>. <literal>"pkgname-unstable-2014-09-23"</literal>.
</para> </para>
</listitem> </listitem>
<listitem> <listitem>
<para> <para>
Dashes in the package name <emphasis>should</emphasis> be preserved in new variable names, Dashes in the package name <emphasis>should</emphasis> be preserved in
rather than converted to underscores or camel cased — e.g., new variable names, rather than converted to underscores or camel cased
<varname>http-parser</varname> instead of <varname>http_parser</varname> — e.g., <varname>http-parser</varname> instead of
or <varname>httpParser</varname>. The hyphenated style is preferred in <varname>http_parser</varname> or <varname>httpParser</varname>. The
all three package names. hyphenated style is preferred in all three package names.
</para> </para>
</listitem> </listitem>
<listitem> <listitem>
<para> <para>
If there are multiple versions of a package, this <emphasis>should</emphasis> be reflected in If there are multiple versions of a package, this
the variable names in <filename>all-packages.nix</filename>, e.g. <emphasis>should</emphasis> be reflected in the variable names in
<varname>json-c-0-9</varname> and <varname>json-c-0-11</varname>. If <filename>all-packages.nix</filename>, e.g. <varname>json-c-0-9</varname>
there is an obvious “default” version, make an attribute like and <varname>json-c-0-11</varname>. If there is an obvious “default”
<literal>json-c = json-c-0-9;</literal>. See also version, make an attribute like <literal>json-c = json-c-0-9;</literal>.
<xref linkend="sec-versioning" /> See also <xref linkend="sec-versioning" />
</para> </para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
@ -814,8 +809,8 @@ args.stdenv.mkDerivation (args // {
<para> <para>
There are multiple ways to fetch a package source in nixpkgs. The general There are multiple ways to fetch a package source in nixpkgs. The general
guideline is that you should package reproducible sources with a high degree of guideline is that you should package reproducible sources with a high degree
availability. Right now there is only one fetcher which has mirroring of availability. Right now there is only one fetcher which has mirroring
support and that is <literal>fetchurl</literal>. Note that you should also support and that is <literal>fetchurl</literal>. Note that you should also
prefer protocols which have a corresponding proxy environment variable. prefer protocols which have a corresponding proxy environment variable.
</para> </para>
@ -869,8 +864,10 @@ src = fetchFromGitHub {
} }
</programlisting> </programlisting>
Find the value to put as <literal>sha256</literal> by running Find the value to put as <literal>sha256</literal> by running
<literal>nix run -f '&lt;nixpkgs&gt;' nix-prefetch-github -c nix-prefetch-github --rev 1f795f9f44607cc5bec70d1300150bfefcef2aae NixOS nix</literal> <literal>nix run -f '&lt;nixpkgs&gt;' nix-prefetch-github -c
or <literal>nix-prefetch-url --unpack https://github.com/NixOS/nix/archive/1f795f9f44607cc5bec70d1300150bfefcef2aae.tar.gz</literal>. nix-prefetch-github --rev 1f795f9f44607cc5bec70d1300150bfefcef2aae NixOS
nix</literal> or <literal>nix-prefetch-url --unpack
https://github.com/NixOS/nix/archive/1f795f9f44607cc5bec70d1300150bfefcef2aae.tar.gz</literal>.
</para> </para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
@ -953,17 +950,23 @@ $ nix-hash --type sha256 --to-base32 <replaceable>HASH</replaceable>
would be replace hash with a fake one and rebuild. Nix build will fail and would be replace hash with a fake one and rebuild. Nix build will fail and
error message will contain desired hash. error message will contain desired hash.
</para> </para>
<warning><para>This method has security problems. Check below for details.</para></warning> <warning>
<para>
This method has security problems. Check below for details.
</para>
</warning>
</listitem> </listitem>
</orderedlist> </orderedlist>
<section xml:id="sec-source-hashes-security"> <section xml:id="sec-source-hashes-security">
<title>Obtaining hashes securely</title> <title>Obtaining hashes securely</title>
<para> <para>
Let's say Man-in-the-Middle (MITM) sits close to your network. Then instead of fetching Let's say Man-in-the-Middle (MITM) sits close to your network. Then instead
source you can fetch malware, and instead of source hash you get hash of malware. Here are of fetching source you can fetch malware, and instead of source hash you
security considerations for this scenario: get hash of malware. Here are security considerations for this scenario:
</para> </para>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para> <para>
@ -972,7 +975,8 @@ $ nix-hash --type sha256 --to-base32 <replaceable>HASH</replaceable>
</listitem> </listitem>
<listitem> <listitem>
<para> <para>
hashes from upstream (in method 3) should be obtained via secure protocol; hashes from upstream (in method 3) should be obtained via secure
protocol;
</para> </para>
</listitem> </listitem>
<listitem> <listitem>
@ -982,12 +986,12 @@ $ nix-hash --type sha256 --to-base32 <replaceable>HASH</replaceable>
</listitem> </listitem>
<listitem> <listitem>
<para> <para>
<literal>https://</literal> URLs are not secure in method 5. When obtaining hashes <literal>https://</literal> URLs are not secure in method 5. When
with fake hash method, TLS checks are disabled. So obtaining hashes with fake hash method, TLS checks are disabled. So
refetch source hash from several different networks to exclude MITM scenario. refetch source hash from several different networks to exclude MITM
Alternatively, use fake hash method to make Nix error, but instead of extracting scenario. Alternatively, use fake hash method to make Nix error, but
hash from error, extract <literal>https://</literal> URL and prefetch it instead of extracting hash from error, extract
with method 1. <literal>https://</literal> URL and prefetch it with method 1.
</para> </para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>

19
doc/configuration.xml
View File

@ -132,13 +132,13 @@
</itemizedlist> </itemizedlist>
<para> <para>
The difference between a package being unsupported on some system and The difference between a package being unsupported on some system and being
being broken is admittedly a bit fuzzy. If a program broken is admittedly a bit fuzzy. If a program <emphasis>ought</emphasis> to
<emphasis>ought</emphasis> to work on a certain platform, but doesn't, the work on a certain platform, but doesn't, the platform should be included in
platform should be included in <literal>meta.platforms</literal>, but marked <literal>meta.platforms</literal>, but marked as broken with e.g.
as broken with e.g. <literal>meta.broken = <literal>meta.broken = !hostPlatform.isWindows</literal>. Of course, this
!hostPlatform.isWindows</literal>. Of course, this begs the question of what begs the question of what "ought" means exactly. That is left to the package
"ought" means exactly. That is left to the package maintainer. maintainer.
</para> </para>
</section> </section>
<section xml:id="sec-allow-unfree"> <section xml:id="sec-allow-unfree">
@ -175,9 +175,8 @@
</programlisting> </programlisting>
</para> </para>
<para> <para>
For a more useful example, try the following. This configuration For a more useful example, try the following. This configuration only
only allows unfree packages named flash player and visual studio allows unfree packages named flash player and visual studio code:
code:
<programlisting> <programlisting>
{ {
allowUnfreePredicate = (pkg: builtins.elem allowUnfreePredicate = (pkg: builtins.elem

144
doc/cross-compilation.xml
View File

@ -6,17 +6,17 @@
<title>Introduction</title> <title>Introduction</title>
<para> <para>
"Cross-compilation" means compiling a program on one machine for another type "Cross-compilation" means compiling a program on one machine for another
of machine. For example, a typical use of cross-compilation is to compile type of machine. For example, a typical use of cross-compilation is to
programs for embedded devices. These devices often don't have the computing compile programs for embedded devices. These devices often don't have the
power and memory to compile their own programs. One might think that computing power and memory to compile their own programs. One might think
cross-compilation is a fairly niche concern. However, there are significant that cross-compilation is a fairly niche concern. However, there are
advantages to rigorously distinguishing between build-time and run-time significant advantages to rigorously distinguishing between build-time and
environments! This applies even when one is developing and deploying on the run-time environments! This applies even when one is developing and
same machine. Nixpkgs is increasingly adopting the opinion that packages deploying on the same machine. Nixpkgs is increasingly adopting the opinion
should be written with cross-compilation in mind, and nixpkgs should evaluate that packages should be written with cross-compilation in mind, and nixpkgs
in a similar way (by minimizing cross-compilation-specific special cases) should evaluate in a similar way (by minimizing cross-compilation-specific
whether or not one is cross-compiling. special cases) whether or not one is cross-compiling.
</para> </para>
<para> <para>
@ -34,7 +34,8 @@
<title>Platform parameters</title> <title>Platform parameters</title>
<para> <para>
Nixpkgs follows the <link Nixpkgs follows the
<link
xlink:href="https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html">conventions xlink:href="https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html">conventions
of GNU autoconf</link>. We distinguish between 3 types of platforms when of GNU autoconf</link>. We distinguish between 3 types of platforms when
building a derivation: <wordasword>build</wordasword>, building a derivation: <wordasword>build</wordasword>,
@ -95,10 +96,10 @@
The build process of certain compilers is written in such a way that the The build process of certain compilers is written in such a way that the
compiler resulting from a single build can itself only produce binaries compiler resulting from a single build can itself only produce binaries
for a single platform. The task of specifying this single "target for a single platform. The task of specifying this single "target
platform" is thus pushed to build time of the compiler. The root cause of platform" is thus pushed to build time of the compiler. The root cause
this is that the compiler (which will be run on the host) and the standard of this is that the compiler (which will be run on the host) and the
library/runtime (which will be run on the target) are built by a single standard library/runtime (which will be run on the target) are built by
build process. a single build process.
</para> </para>
<para> <para>
There is no fundamental need to think about a single target ahead of There is no fundamental need to think about a single target ahead of
@ -136,9 +137,9 @@
This is a two-component shorthand for the platform. Examples of this This is a two-component shorthand for the platform. Examples of this
would be "x86_64-darwin" and "i686-linux"; see would be "x86_64-darwin" and "i686-linux"; see
<literal>lib.systems.doubles</literal> for more. The first component <literal>lib.systems.doubles</literal> for more. The first component
corresponds to the CPU architecture of the platform and the second to the corresponds to the CPU architecture of the platform and the second to
operating system of the platform (<literal>[cpu]-[os]</literal>). This the operating system of the platform (<literal>[cpu]-[os]</literal>).
format has built-in support in Nix, such as the This format has built-in support in Nix, such as the
<varname>builtins.currentSystem</varname> impure string. <varname>builtins.currentSystem</varname> impure string.
</para> </para>
</listitem> </listitem>
@ -149,14 +150,14 @@
</term> </term>
<listitem> <listitem>
<para> <para>
This is a 3- or 4- component shorthand for the platform. Examples of this This is a 3- or 4- component shorthand for the platform. Examples of
would be <literal>x86_64-unknown-linux-gnu</literal> and this would be <literal>x86_64-unknown-linux-gnu</literal> and
<literal>aarch64-apple-darwin14</literal>. This is a standard format <literal>aarch64-apple-darwin14</literal>. This is a standard format
called the "LLVM target triple", as they are pioneered by LLVM. In the called the "LLVM target triple", as they are pioneered by LLVM. In the
4-part form, this corresponds to 4-part form, this corresponds to
<literal>[cpu]-[vendor]-[os]-[abi]</literal>. This format is strictly <literal>[cpu]-[vendor]-[os]-[abi]</literal>. This format is strictly
more informative than the "Nix host double", as the previous format could more informative than the "Nix host double", as the previous format
analogously be termed. This needs a better name than could analogously be termed. This needs a better name than
<varname>config</varname>! <varname>config</varname>!
</para> </para>
</listitem> </listitem>
@ -167,11 +168,10 @@
</term> </term>
<listitem> <listitem>
<para> <para>
This is a Nix representation of a parsed LLVM target triple This is a Nix representation of a parsed LLVM target triple with
with white-listed components. This can be specified directly, white-listed components. This can be specified directly, or actually
or actually parsed from the <varname>config</varname>. See parsed from the <varname>config</varname>. See
<literal>lib.systems.parse</literal> for the exact <literal>lib.systems.parse</literal> for the exact representation.
representation.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -253,15 +253,15 @@
<para> <para>
Some examples will make this clearer. If a package is being built with a Some examples will make this clearer. If a package is being built with a
<literal>(build, host, target)</literal> platform triple of <literal>(foo, <literal>(build, host, target)</literal> platform triple of <literal>(foo,
bar, bar)</literal>, then its build-time dependencies would have a triple of bar, bar)</literal>, then its build-time dependencies would have a triple
<literal>(foo, foo, bar)</literal>, and <emphasis>those packages'</emphasis> of <literal>(foo, foo, bar)</literal>, and <emphasis>those
build-time dependencies would have a triple of <literal>(foo, foo, packages'</emphasis> build-time dependencies would have a triple of
foo)</literal>. In other words, it should take two "rounds" of following <literal>(foo, foo, foo)</literal>. In other words, it should take two
build-time dependency edges before one reaches a fixed point where, by the "rounds" of following build-time dependency edges before one reaches a
sliding window principle, the platform triple no longer changes. Indeed, fixed point where, by the sliding window principle, the platform triple no
this happens with cross-compilation, where only rounds of native longer changes. Indeed, this happens with cross-compilation, where only
dependencies starting with the second necessarily coincide with native rounds of native dependencies starting with the second necessarily coincide
packages. with native packages.
</para> </para>
<note> <note>
@ -273,23 +273,24 @@
</note> </note>
<para> <para>
How does this work in practice? Nixpkgs is now structured so that build-time How does this work in practice? Nixpkgs is now structured so that
dependencies are taken from <varname>buildPackages</varname>, whereas build-time dependencies are taken from <varname>buildPackages</varname>,
run-time dependencies are taken from the top level attribute set. For whereas run-time dependencies are taken from the top level attribute set.
example, <varname>buildPackages.gcc</varname> should be used at build-time, For example, <varname>buildPackages.gcc</varname> should be used at
while <varname>gcc</varname> should be used at run-time. Now, for most of build-time, while <varname>gcc</varname> should be used at run-time. Now,
Nixpkgs's history, there was no <varname>buildPackages</varname>, and most for most of Nixpkgs's history, there was no
packages have not been refactored to use it explicitly. Instead, one can use <varname>buildPackages</varname>, and most packages have not been
the six (<emphasis>gasp</emphasis>) attributes used for specifying refactored to use it explicitly. Instead, one can use the six
dependencies as documented in <xref linkend="ssec-stdenv-dependencies"/>. We (<emphasis>gasp</emphasis>) attributes used for specifying dependencies as
"splice" together the run-time and build-time package sets with documented in <xref linkend="ssec-stdenv-dependencies"/>. We "splice"
<varname>callPackage</varname>, and then <varname>mkDerivation</varname> for together the run-time and build-time package sets with
each of four attributes pulls the right derivation out. This splicing can be <varname>callPackage</varname>, and then <varname>mkDerivation</varname>
skipped when not cross-compiling as the package sets are the same, but is a for each of four attributes pulls the right derivation out. This splicing
bit slow for cross-compiling. Because of this, a best-of-both-worlds can be skipped when not cross-compiling as the package sets are the same,
solution is in the works with no splicing or explicit access of but is a bit slow for cross-compiling. Because of this, a
<varname>buildPackages</varname> needed. For now, feel free to use either best-of-both-worlds solution is in the works with no splicing or explicit
method. access of <varname>buildPackages</varname> needed. For now, feel free to
use either method.
</para> </para>
<note> <note>
@ -311,8 +312,8 @@
should be answered here. Ideally, the information above is exhaustive, so should be answered here. Ideally, the information above is exhaustive, so
this section cannot provide any new information, but it is ludicrous and this section cannot provide any new information, but it is ludicrous and
cruel to expect everyone to spend effort working through the interaction of cruel to expect everyone to spend effort working through the interaction of
many features just to figure out the same answer to the same common problem. many features just to figure out the same answer to the same common
Feel free to add to this list! problem. Feel free to add to this list!
</para> </para>
<qandaset> <qandaset>
@ -434,14 +435,15 @@ nix-build &lt;nixpkgs&gt; --arg crossSystem '{ config = "&lt;arch&gt;-&lt;os&gt;
build plan or package set. A simple "build vs deploy" dichotomy is adequate: build plan or package set. A simple "build vs deploy" dichotomy is adequate:
the sliding window principle described in the previous section shows how to the sliding window principle described in the previous section shows how to
interpolate between the these two "end points" to get the 3 platform triple interpolate between the these two "end points" to get the 3 platform triple
for each bootstrapping stage. That means for any package a given package set, for each bootstrapping stage. That means for any package a given package
even those not bound on the top level but only reachable via dependencies or set, even those not bound on the top level but only reachable via
<varname>buildPackages</varname>, the three platforms will be defined as one dependencies or <varname>buildPackages</varname>, the three platforms will
of <varname>localSystem</varname> or <varname>crossSystem</varname>, with the be defined as one of <varname>localSystem</varname> or
former replacing the latter as one traverses build-time dependencies. A last <varname>crossSystem</varname>, with the former replacing the latter as one
simple difference is that <varname>crossSystem</varname> should be null when traverses build-time dependencies. A last simple difference is that
one doesn't want to cross-compile, while the <varname>*Platform</varname>s <varname>crossSystem</varname> should be null when one doesn't want to
are always non-null. <varname>localSystem</varname> is always non-null. cross-compile, while the <varname>*Platform</varname>s are always non-null.
<varname>localSystem</varname> is always non-null.
</para> </para>
</section> </section>
<!--============================================================--> <!--============================================================-->
@ -455,13 +457,13 @@ nix-build &lt;nixpkgs&gt; --arg crossSystem '{ config = "&lt;arch&gt;-&lt;os&gt;
<note> <note>
<para> <para>
If one explores Nixpkgs, they will see derivations with names like If one explores Nixpkgs, they will see derivations with names like
<literal>gccCross</literal>. Such <literal>*Cross</literal> derivations is a <literal>gccCross</literal>. Such <literal>*Cross</literal> derivations is
holdover from before we properly distinguished between the host and target a holdover from before we properly distinguished between the host and
platforms—the derivation with "Cross" in the name covered the <literal>build target platforms—the derivation with "Cross" in the name covered the
= host != target</literal> case, while the other covered the <literal>host = <literal>build = host != target</literal> case, while the other covered the
target</literal>, with build platform the same or not based on whether one <literal>host = target</literal>, with build platform the same or not based
was using its <literal>.nativeDrv</literal> or <literal>.crossDrv</literal>. on whether one was using its <literal>.nativeDrv</literal> or
This ugliness will disappear soon. <literal>.crossDrv</literal>. This ugliness will disappear soon.
</para> </para>
</note> </note>
</section> </section>

41
doc/functions/appimagetools.xml
View File

@ -5,11 +5,11 @@
<title>pkgs.appimageTools</title> <title>pkgs.appimageTools</title>
<para> <para>
<varname>pkgs.appimageTools</varname> is a set of functions for extracting and wrapping <varname>pkgs.appimageTools</varname> is a set of functions for extracting
<link xlink:href="https://appimage.org/">AppImage</link> files. and wrapping <link xlink:href="https://appimage.org/">AppImage</link> files.
They are meant to be used if traditional packaging from source is infeasible,
They are meant to be used if traditional packaging from source is infeasible, or it would take too long. or it would take too long. To quickly run an AppImage file,
To quickly run an AppImage file, <literal>pkgs.appimage-run</literal> can be used as well. <literal>pkgs.appimage-run</literal> can be used as well.
</para> </para>
<warning> <warning>
@ -19,13 +19,13 @@
</para> </para>
</warning> </warning>
<section xml:id="ssec-pkgs-appimageTools-formats"> <section xml:id="ssec-pkgs-appimageTools-formats">
<title>AppImage formats</title> <title>AppImage formats</title>
<para> <para>
There are different formats for AppImages, see There are different formats for AppImages, see
<link xlink:href="https://github.com/AppImage/AppImageSpec/blob/74ad9ca2f94bf864a4a0dac1f369dd4f00bd1c28/draft.md#image-format">the specification</link> for details. <link xlink:href="https://github.com/AppImage/AppImageSpec/blob/74ad9ca2f94bf864a4a0dac1f369dd4f00bd1c28/draft.md#image-format">the
specification</link> for details.
</para> </para>
<itemizedlist> <itemizedlist>
@ -34,7 +34,6 @@
Type 1 images are ISO 9660 files that are also ELF executables. Type 1 images are ISO 9660 files that are also ELF executables.
</para> </para>
</listitem> </listitem>
<listitem> <listitem>
<para> <para>
Type 2 images are ELF executables with an appended filesystem. Type 2 images are ELF executables with an appended filesystem.
@ -56,7 +55,8 @@ type2.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) (Lepton 3.x)
</screen> </screen>
<para> <para>
Note how the type 1 AppImage is described as an <literal>ISO 9660 CD-ROM filesystem</literal>, and the type 2 AppImage is not. Note how the type 1 AppImage is described as an <literal>ISO 9660 CD-ROM
filesystem</literal>, and the type 2 AppImage is not.
</para> </para>
</section> </section>
@ -68,7 +68,6 @@ type2.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) (Lepton 3.x)
<varname>wrapType1</varname> or <varname>wrapType2</varname>. <varname>wrapType1</varname> or <varname>wrapType2</varname>.
</para> </para>
<programlisting> <programlisting>
appimageTools.wrapType2 { # or wrapType1 appimageTools.wrapType2 { # or wrapType1
name = "patchwork"; <co xml:id='ex-appimageTools-wrapping-1' /> name = "patchwork"; <co xml:id='ex-appimageTools-wrapping-1' />
@ -79,7 +78,6 @@ appimageTools.wrapType2 { # or wrapType1
extraPkgs = pkgs: with pkgs; [ ]; <co xml:id='ex-appimageTools-wrapping-3' /> extraPkgs = pkgs: with pkgs; [ ]; <co xml:id='ex-appimageTools-wrapping-3' />
}</programlisting> }</programlisting>
<calloutlist> <calloutlist>
<callout arearefs='ex-appimageTools-wrapping-1'> <callout arearefs='ex-appimageTools-wrapping-1'>
<para> <para>
@ -93,29 +91,28 @@ appimageTools.wrapType2 { # or wrapType1
</callout> </callout>
<callout arearefs='ex-appimageTools-wrapping-2'> <callout arearefs='ex-appimageTools-wrapping-2'>
<para> <para>
<varname>extraPkgs</varname> allows you to pass a function to include additional packages <varname>extraPkgs</varname> allows you to pass a function to include
inside the FHS environment your AppImage is going to run in. additional packages inside the FHS environment your AppImage is going to
run in. There are a few ways to learn which dependencies an application
There are a few ways to learn which dependencies an application needs: needs:
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para> <para>
Looking through the extracted AppImage files, reading its scripts and running <command>patchelf</command> and <command>ldd</command> on its executables. Looking through the extracted AppImage files, reading its scripts and
This can also be done in <command>appimage-run</command>, by setting <command>APPIMAGE_DEBUG_EXEC=bash</command>. running <command>patchelf</command> and <command>ldd</command> on its
executables. This can also be done in <command>appimage-run</command>,
by setting <command>APPIMAGE_DEBUG_EXEC=bash</command>.
</para> </para>
</listitem> </listitem>
<listitem> <listitem>
<para> <para>
Running <command>strace -vfefile</command> on the wrapped executable, looking for libraries that can't be found. Running <command>strace -vfefile</command> on the wrapped executable,
looking for libraries that can't be found.
</para> </para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
</para> </para>
</callout> </callout>
</calloutlist> </calloutlist>
</section> </section>
</section> </section>

24
doc/functions/dockertools.xml
View File

@ -24,9 +24,9 @@
<para> <para>
This function is analogous to the <command>docker build</command> command, This function is analogous to the <command>docker build</command> command,
in that it can be used to build a Docker-compatible repository tarball containing in that it can be used to build a Docker-compatible repository tarball
a single image with one or multiple layers. As such, the result is suitable containing a single image with one or multiple layers. As such, the result
for being loaded in Docker with <command>docker load</command>. is suitable for being loaded in Docker with <command>docker load</command>.
</para> </para>
<para> <para>
@ -190,8 +190,8 @@ buildImage {
By default <function>buildImage</function> will use a static date of one By default <function>buildImage</function> will use a static date of one
second past the UNIX Epoch. This allows <function>buildImage</function> to second past the UNIX Epoch. This allows <function>buildImage</function> to
produce binary reproducible images. When listing images with produce binary reproducible images. When listing images with
<command>docker images</command>, the newly created images will be <command>docker images</command>, the newly created images will be listed
listed like this: like this:
</para> </para>
<screen><![CDATA[ <screen><![CDATA[
$ docker images $ docker images
@ -402,9 +402,9 @@ pkgs.dockerTools.buildLayeredImage {
<para> <para>
This function is analogous to the <command>docker pull</command> command, in This function is analogous to the <command>docker pull</command> command, in
that it can be used to pull a Docker image from a Docker registry. By default that it can be used to pull a Docker image from a Docker registry. By
<link xlink:href="https://hub.docker.com/">Docker Hub</link> is used to pull default <link xlink:href="https://hub.docker.com/">Docker Hub</link> is used
images. to pull images.
</para> </para>
<para> <para>
@ -484,10 +484,10 @@ sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b
<para> <para>
This function is analogous to the <command>docker export</command> command, This function is analogous to the <command>docker export</command> command,
in that it can be used to flatten a Docker image that contains multiple layers. It in that it can be used to flatten a Docker image that contains multiple
is in fact the result of the merge of all the layers of the image. As such, layers. It is in fact the result of the merge of all the layers of the
the result is suitable for being imported in Docker with <command>docker image. As such, the result is suitable for being imported in Docker with
import</command>. <command>docker import</command>.
</para> </para>
<note> <note>

114
doc/functions/fetchers.xml
View File

@ -5,21 +5,18 @@
<title>Fetcher functions</title> <title>Fetcher functions</title>
<para> <para>
When using Nix, you will frequently need to download source code When using Nix, you will frequently need to download source code and other
and other files from the internet. Nixpkgs comes with a few helper files from the internet. Nixpkgs comes with a few helper functions that allow
functions that allow you to fetch fixed-output derivations in a you to fetch fixed-output derivations in a structured way.
structured way.
</para> </para>
<para> <para>
The two fetcher primitives are <function>fetchurl</function> and The two fetcher primitives are <function>fetchurl</function> and
<function>fetchzip</function>. Both of these have two required <function>fetchzip</function>. Both of these have two required arguments, a
arguments, a URL and a hash. The hash is typically URL and a hash. The hash is typically <literal>sha256</literal>, although
<literal>sha256</literal>, although many more hash algorithms are many more hash algorithms are supported. Nixpkgs contributors are currently
supported. Nixpkgs contributors are currently recommended to use recommended to use <literal>sha256</literal>. This hash will be used by Nix
<literal>sha256</literal>. This hash will be used by Nix to to identify your source. A typical usage of fetchurl is provided below.
identify your source. A typical usage of fetchurl is provided
below.
</para> </para>
<programlisting><![CDATA[ <programlisting><![CDATA[
@ -37,30 +34,28 @@ stdenv.mkDerivation {
<para> <para>
The main difference between <function>fetchurl</function> and The main difference between <function>fetchurl</function> and
<function>fetchzip</function> is in how they store the contents. <function>fetchzip</function> is in how they store the contents.
<function>fetchurl</function> will store the unaltered contents of <function>fetchurl</function> will store the unaltered contents of the URL
the URL within the Nix store. <function>fetchzip</function> on the within the Nix store. <function>fetchzip</function> on the other hand will
other hand will decompress the archive for you, making files and decompress the archive for you, making files and directories directly
directories directly accessible in the future. accessible in the future. <function>fetchzip</function> can only be used with
<function>fetchzip</function> can only be used with archives. archives. Despite the name, <function>fetchzip</function> is not limited to
Despite the name, <function>fetchzip</function> is not limited to
.zip files and can also be used with any tarball. .zip files and can also be used with any tarball.
</para> </para>
<para> <para>
<function>fetchpatch</function> works very similarly to <function>fetchpatch</function> works very similarly to
<function>fetchurl</function> with the same arguments expected. It <function>fetchurl</function> with the same arguments expected. It expects
expects patch files as a source and and performs normalization on patch files as a source and and performs normalization on them before
them before computing the checksum. For example it will remove computing the checksum. For example it will remove comments or other unstable
comments or other unstable parts that are sometimes added by parts that are sometimes added by version control systems and can change over
version control systems and can change over time. time.
</para> </para>
<para> <para>
Other fetcher functions allow you to add source code directly from Other fetcher functions allow you to add source code directly from a VCS such
a VCS such as subversion or git. These are mostly straightforward as subversion or git. These are mostly straightforward names based on the
names based on the name of the command used with the VCS system. name of the command used with the VCS system. Because they give you a working
Because they give you a working repository, they act most like repository, they act most like <function>fetchzip</function>.
<function>fetchzip</function>.
</para> </para>
<variablelist> <variablelist>
@ -70,9 +65,8 @@ stdenv.mkDerivation {
</term> </term>
<listitem> <listitem>
<para> <para>
Used with Subversion. Expects <literal>url</literal> to a Used with Subversion. Expects <literal>url</literal> to a Subversion
Subversion directory, <literal>rev</literal>, and directory, <literal>rev</literal>, and <literal>sha256</literal>.
<literal>sha256</literal>.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -84,9 +78,8 @@ stdenv.mkDerivation {
<para> <para>
Used with Git. Expects <literal>url</literal> to a Git repo, Used with Git. Expects <literal>url</literal> to a Git repo,
<literal>rev</literal>, and <literal>sha256</literal>. <literal>rev</literal>, and <literal>sha256</literal>.
<literal>rev</literal> in this case can be full the git commit <literal>rev</literal> in this case can be full the git commit id (SHA1
id (SHA1 hash) or a tag name like hash) or a tag name like <literal>refs/tags/v1.0</literal>.
<literal>refs/tags/v1.0</literal>.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -96,8 +89,8 @@ stdenv.mkDerivation {
</term> </term>
<listitem> <listitem>
<para> <para>
Used with Fossil. Expects <literal>url</literal> to a Fossil Used with Fossil. Expects <literal>url</literal> to a Fossil archive,
archive, <literal>rev</literal>, and <literal>sha256</literal>. <literal>rev</literal>, and <literal>sha256</literal>.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -107,8 +100,8 @@ stdenv.mkDerivation {
</term> </term>
<listitem> <listitem>
<para> <para>
Used with CVS. Expects <literal>cvsRoot</literal>, Used with CVS. Expects <literal>cvsRoot</literal>, <literal>tag</literal>,
<literal>tag</literal>, and <literal>sha256</literal>. and <literal>sha256</literal>.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -126,11 +119,10 @@ stdenv.mkDerivation {
</variablelist> </variablelist>
<para> <para>
A number of fetcher functions wrap part of A number of fetcher functions wrap part of <function>fetchurl</function> and
<function>fetchurl</function> and <function>fetchzip</function>. <function>fetchzip</function>. They are mainly convenience functions intended
They are mainly convenience functions intended for commonly used for commonly used destinations of source code in Nixpkgs. These wrapper
destinations of source code in Nixpkgs. These wrapper fetchers are fetchers are listed below.
listed below.
</para> </para>
<variablelist> <variablelist>
@ -141,17 +133,15 @@ stdenv.mkDerivation {
<listitem> <listitem>
<para> <para>
<function>fetchFromGitHub</function> expects four arguments. <function>fetchFromGitHub</function> expects four arguments.
<literal>owner</literal> is a string corresponding to the <literal>owner</literal> is a string corresponding to the GitHub user or
GitHub user or organization that controls this repository. organization that controls this repository. <literal>repo</literal>
<literal>repo</literal> corresponds to the name of the corresponds to the name of the software repository. These are located at
software repository. These are located at the top of every the top of every GitHub HTML page as
GitHub HTML page as <literal>owner</literal>/<literal>repo</literal>. <literal>rev</literal>
<literal>owner</literal>/<literal>repo</literal>. corresponds to the Git commit hash or tag (e.g <literal>v1.0</literal>)
<literal>rev</literal> corresponds to the Git commit hash or that will be downloaded from Git. Finally, <literal>sha256</literal>
tag (e.g <literal>v1.0</literal>) that will be downloaded from corresponds to the hash of the extracted directory. Again, other hash
Git. Finally, <literal>sha256</literal> corresponds to the algorithms are also available but <literal>sha256</literal> is currently
hash of the extracted directory. Again, other hash algorithms
are also available but <literal>sha256</literal> is currently
preferred. preferred.
</para> </para>
</listitem> </listitem>
@ -162,8 +152,8 @@ stdenv.mkDerivation {
</term> </term>
<listitem> <listitem>
<para> <para>
This is used with GitLab repositories. The arguments expected This is used with GitLab repositories. The arguments expected are very
are very similar to fetchFromGitHub above. similar to fetchFromGitHub above.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -173,8 +163,8 @@ stdenv.mkDerivation {
</term> </term>
<listitem> <listitem>
<para> <para>
This is used with BitBucket repositories. The arguments expected This is used with BitBucket repositories. The arguments expected are very
are very similar to fetchFromGitHub above. similar to fetchFromGitHub above.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -184,8 +174,8 @@ stdenv.mkDerivation {
</term> </term>
<listitem> <listitem>
<para> <para>
This is used with Savannah repositories. The arguments expected This is used with Savannah repositories. The arguments expected are very
are very similar to fetchFromGitHub above. similar to fetchFromGitHub above.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -195,12 +185,10 @@ stdenv.mkDerivation {
</term> </term>
<listitem> <listitem>
<para> <para>
This is used with repo.or.cz repositories. The arguments This is used with repo.or.cz repositories. The arguments expected are very
expected are very similar to fetchFromGitHub above. similar to fetchFromGitHub above.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
</variablelist> </variablelist>
</section> </section>

5
doc/functions/library.xml
View File

@ -16,9 +16,14 @@
<!-- These docs are generated via nixdoc. To add another generated <!-- These docs are generated via nixdoc. To add another generated
library function file to this list, the file library function file to this list, the file
`lib-function-docs.nix` must also be updated. --> `lib-function-docs.nix` must also be updated. -->
<xi:include href="./library/generated/strings.xml" /> <xi:include href="./library/generated/strings.xml" />
<xi:include href="./library/generated/trivial.xml" /> <xi:include href="./library/generated/trivial.xml" />
<xi:include href="./library/generated/lists.xml" /> <xi:include href="./library/generated/lists.xml" />
<xi:include href="./library/generated/debug.xml" /> <xi:include href="./library/generated/debug.xml" />
<xi:include href="./library/generated/options.xml" /> <xi:include href="./library/generated/options.xml" />
</section> </section>

20
doc/functions/nix-gitignore.xml
View File

@ -17,9 +17,9 @@
<literal>pkgs.nix-gitignore</literal> exports a number of functions, but <literal>pkgs.nix-gitignore</literal> exports a number of functions, but
you'll most likely need either <literal>gitignoreSource</literal> or you'll most likely need either <literal>gitignoreSource</literal> or
<literal>gitignoreSourcePure</literal>. As their first argument, they both <literal>gitignoreSourcePure</literal>. As their first argument, they both
accept either 1. a file with gitignore lines or 2. a string accept either 1. a file with gitignore lines or 2. a string with gitignore
with gitignore lines, or 3. a list of either of the two. They will be lines, or 3. a list of either of the two. They will be concatenated into a
concatenated into a single big string. single big string.
</para> </para>
<programlisting><![CDATA[ <programlisting><![CDATA[
@ -40,8 +40,8 @@
]]></programlisting> ]]></programlisting>
<para> <para>
These functions are derived from the <literal>Filter</literal> functions These functions are derived from the <literal>Filter</literal> functions by
by setting the first filter argument to <literal>(_: _: true)</literal>: setting the first filter argument to <literal>(_: _: true)</literal>:
</para> </para>
<programlisting><![CDATA[ <programlisting><![CDATA[
@ -50,7 +50,12 @@ gitignoreSource = gitignoreFilterSource (_: _: true);
]]></programlisting> ]]></programlisting>
<para> <para>
Those filter functions accept the same arguments the <literal>builtins.filterSource</literal> function would pass to its filters, thus <literal>fn: gitignoreFilterSourcePure fn ""</literal> should be extensionally equivalent to <literal>filterSource</literal>. The file is blacklisted iff it's blacklisted by either your filter or the gitignoreFilter. Those filter functions accept the same arguments the
<literal>builtins.filterSource</literal> function would pass to its filters,
thus <literal>fn: gitignoreFilterSourcePure fn ""</literal> should be
extensionally equivalent to <literal>filterSource</literal>. The file is
blacklisted iff it's blacklisted by either your filter or the
gitignoreFilter.
</para> </para>
<para> <para>
@ -66,7 +71,8 @@ gitignoreFilter = ign: root: filterPattern (gitignoreToPatterns ign) root;
<title>gitignore files in subdirectories</title> <title>gitignore files in subdirectories</title>
<para> <para>
If you wish to use a filter that would search for .gitignore files in subdirectories, just like git does by default, use this function: If you wish to use a filter that would search for .gitignore files in
subdirectories, just like git does by default, use this function:
</para> </para>
<programlisting><![CDATA[ <programlisting><![CDATA[

10
doc/functions/prefer-remote-fetch.xml
View File

@ -7,16 +7,14 @@
<para> <para>
<function>prefer-remote-fetch</function> is an overlay that download sources <function>prefer-remote-fetch</function> is an overlay that download sources
on remote builder. This is useful when the evaluating machine has a slow on remote builder. This is useful when the evaluating machine has a slow
upload while the builder can fetch faster directly from the source. upload while the builder can fetch faster directly from the source. To use
To use it, put the following snippet as a new overlay: it, put the following snippet as a new overlay:
<programlisting> <programlisting>
self: super: self: super:
(super.prefer-remote-fetch self super) (super.prefer-remote-fetch self super)
</programlisting> </programlisting>
A full configuration example for that sets the overlay up for your own
A full configuration example for that sets the overlay up for your own account, account, could look like this
could look like this
<programlisting> <programlisting>
$ mkdir ~/.config/nixpkgs/overlays/ $ mkdir ~/.config/nixpkgs/overlays/
$ cat &gt; ~/.config/nixpkgs/overlays/prefer-remote-fetch.nix &lt;&lt;EOF $ cat &gt; ~/.config/nixpkgs/overlays/prefer-remote-fetch.nix &lt;&lt;EOF

87
doc/functions/trivial-builders.xml
View File

@ -5,12 +5,11 @@
<title>Trivial builders</title> <title>Trivial builders</title>
<para> <para>
Nixpkgs provides a couple of functions that help with building Nixpkgs provides a couple of functions that help with building derivations.
derivations. The most important one, The most important one, <function>stdenv.mkDerivation</function>, has already
<function>stdenv.mkDerivation</function>, has already been been documented above. The following functions wrap
documented above. The following functions wrap <function>stdenv.mkDerivation</function>, making it easier to use in certain
<function>stdenv.mkDerivation</function>, making it easier to use cases.
in certain cases.
</para> </para>
<variablelist> <variablelist>
@ -22,21 +21,18 @@
<para> <para>
This takes three arguments, <literal>name</literal>, This takes three arguments, <literal>name</literal>,
<literal>env</literal>, and <literal>buildCommand</literal>. <literal>env</literal>, and <literal>buildCommand</literal>.
<literal>name</literal> is just the name that Nix will append <literal>name</literal> is just the name that Nix will append to the store
to the store path in the same way that path in the same way that <literal>stdenv.mkDerivation</literal> uses its
<literal>stdenv.mkDerivation</literal> uses its <literal>name</literal> attribute. <literal>env</literal> is an attribute
<literal>name</literal> attribute. <literal>env</literal> is an set specifying environment variables that will be set for this derivation.
attribute set specifying environment variables that will be set These attributes are then passed to the wrapped
for this derivation. These attributes are then passed to the <literal>stdenv.mkDerivation</literal>. <literal>buildCommand</literal>
wrapped <literal>stdenv.mkDerivation</literal>. specifies the commands that will be run to create this derivation. Note
<literal>buildCommand</literal> specifies the commands that that you will need to create <literal>$out</literal> for Nix to register
will be run to create this derivation. Note that you will need the command as successful.
to create <literal>$out</literal> for Nix to register the
command as successful.
</para> </para>
<para> <para>
An example of using <literal>runCommand</literal> is provided An example of using <literal>runCommand</literal> is provided below.
below.
</para> </para>
<programlisting> <programlisting>
(import &lt;nixpkgs&gt; {}).runCommand "my-example" {} '' (import &lt;nixpkgs&gt; {}).runCommand "my-example" {} ''
@ -66,39 +62,33 @@
</term> </term>
<listitem> <listitem>
<para> <para>
This works just like <literal>runCommand</literal>. The only This works just like <literal>runCommand</literal>. The only difference is
difference is that it also provides a C compiler in that it also provides a C compiler in <literal>buildCommand</literal>’s
<literal>buildCommand</literal>’s environment. To minimize your environment. To minimize your dependencies, you should only use this if
dependencies, you should only use this if you are sure you will you are sure you will need a C compiler as part of running your command.
need a C compiler as part of running your command.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term> <term>
<literal>writeTextFile</literal>, <literal>writeText</literal>, <literal>writeTextFile</literal>, <literal>writeText</literal>, <literal>writeTextDir</literal>, <literal>writeScript</literal>, <literal>writeScriptBin</literal>
<literal>writeTextDir</literal>, <literal>writeScript</literal>,
<literal>writeScriptBin</literal>
</term> </term>
<listitem> <listitem>
<para> <para>
These functions write <literal>text</literal> to the Nix store. These functions write <literal>text</literal> to the Nix store. This is
This is useful for creating scripts from Nix expressions. useful for creating scripts from Nix expressions.
<literal>writeTextFile</literal> takes an attribute set and <literal>writeTextFile</literal> takes an attribute set and expects two
expects two arguments, <literal>name</literal> and arguments, <literal>name</literal> and <literal>text</literal>.
<literal>text</literal>. <literal>name</literal> corresponds to <literal>name</literal> corresponds to the name used in the Nix store
the name used in the Nix store path. <literal>text</literal> path. <literal>text</literal> will be the contents of the file. You can
will be the contents of the file. You can also set also set <literal>executable</literal> to true to make this file have the
<literal>executable</literal> to true to make this file have executable bit set.
the executable bit set.
</para> </para>
<para> <para>
Many more commands wrap <literal>writeTextFile</literal> Many more commands wrap <literal>writeTextFile</literal> including
including <literal>writeText</literal>, <literal>writeText</literal>, <literal>writeTextDir</literal>,
<literal>writeTextDir</literal>, <literal>writeScript</literal>, and <literal>writeScriptBin</literal>.
<literal>writeScript</literal>, and These are convenience functions over <literal>writeTextFile</literal>.
<literal>writeScriptBin</literal>. These are convenience
functions over <literal>writeTextFile</literal>.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -109,16 +99,15 @@
<listitem> <listitem>
<para> <para>
This can be used to put many derivations into the same directory This can be used to put many derivations into the same directory
structure. It works by creating a new derivation and adding structure. It works by creating a new derivation and adding symlinks to
symlinks to each of the paths listed. It expects two arguments, each of the paths listed. It expects two arguments,
<literal>name</literal>, and <literal>paths</literal>. <literal>name</literal>, and <literal>paths</literal>.
<literal>name</literal> is the name used in the Nix store path <literal>name</literal> is the name used in the Nix store path for the
for the created derivation. <literal>paths</literal> is a list of created derivation. <literal>paths</literal> is a list of paths that will
paths that will be symlinked. These paths can be to Nix store be symlinked. These paths can be to Nix store derivations or any other
derivations or any other subdirectory contained within. subdirectory contained within.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
</variablelist> </variablelist>
</section> </section>

42
doc/languages-frameworks/ocaml.xml
View File

@ -7,33 +7,32 @@
OCaml libraries should be installed in OCaml libraries should be installed in
<literal>$(out)/lib/ocaml/${ocaml.version}/site-lib/</literal>. Such <literal>$(out)/lib/ocaml/${ocaml.version}/site-lib/</literal>. Such
directories are automatically added to the <literal>$OCAMLPATH</literal> directories are automatically added to the <literal>$OCAMLPATH</literal>
environment variable when building another package that depends on them environment variable when building another package that depends on them or
or when opening a <literal>nix-shell</literal>. when opening a <literal>nix-shell</literal>.
</para> </para>
<para> <para>
Given that most of the OCaml ecosystem is now built with dune, Given that most of the OCaml ecosystem is now built with dune, nixpkgs
nixpkgs includes a convenience build support function called includes a convenience build support function called
<literal>buildDunePackage</literal> that will build an OCaml package <literal>buildDunePackage</literal> that will build an OCaml package using
using dune, OCaml and findlib and any additional dependencies provided dune, OCaml and findlib and any additional dependencies provided as
as <literal>buildInputs</literal> or <literal>propagatedBuildInputs</literal>. <literal>buildInputs</literal> or <literal>propagatedBuildInputs</literal>.
</para> </para>
<para> <para>
Here is a simple package example. It defines an (optional) attribute Here is a simple package example. It defines an (optional) attribute
<literal>minimumOCamlVersion</literal> that will be used to throw a <literal>minimumOCamlVersion</literal> that will be used to throw a
descriptive evaluation error if building with an older OCaml is attempted. descriptive evaluation error if building with an older OCaml is attempted. It
It uses the <literal>fetchFromGitHub</literal> fetcher to get its source. uses the <literal>fetchFromGitHub</literal> fetcher to get its source. It
It sets the <literal>doCheck</literal> (optional) attribute to sets the <literal>doCheck</literal> (optional) attribute to
<literal>true</literal> which means that tests will be run with <literal>true</literal> which means that tests will be run with <literal>dune
<literal>dune runtest -p angstrom</literal> after the build runtest -p angstrom</literal> after the build (<literal>dune build -p
(<literal>dune build -p angstrom</literal>) is complete. angstrom</literal>) is complete. It uses <literal>alcotest</literal> as a
It uses <literal>alcotest</literal> as a build input (because it is needed build input (because it is needed to run the tests) and
to run the tests) and <literal>bigstringaf</literal> and <literal>bigstringaf</literal> and <literal>result</literal> as propagated
<literal>result</literal> as propagated build inputs (thus they will also build inputs (thus they will also be available to libraries depending on this
be available to libraries depending on this library). library). The library will be installed using the
The library will be installed using the <literal>angstrom.install</literal> <literal>angstrom.install</literal> file that dune generates.
file that dune generates.
</para> </para>
<programlisting> <programlisting>
@ -69,8 +68,8 @@ buildDunePackage rec {
Here is a second example, this time using a source archive generated with Here is a second example, this time using a source archive generated with
<literal>dune-release</literal>. It is a good idea to use this archive when <literal>dune-release</literal>. It is a good idea to use this archive when
it is available as it will usually contain substituted variables such as a it is available as it will usually contain substituted variables such as a
<literal>%%VERSION%%</literal> field. This library does not depend <literal>%%VERSION%%</literal> field. This library does not depend on any
on any other OCaml library and no tests are run after building it. other OCaml library and no tests are run after building it.
</para> </para>
<programlisting> <programlisting>
@ -95,5 +94,4 @@ buildDunePackage rec {
}; };
} }
</programlisting> </programlisting>
</section> </section>

9
doc/package-notes.xml
View File

@ -307,19 +307,20 @@ packageOverrides = pkgs: {
</screen> </screen>
</para> </para>
</section> </section>
<section xml:id="sec-elm"> <section xml:id="sec-elm">
<title>Elm</title> <title>Elm</title>
<para> <para>
To update Elm compiler, see <filename>nixpkgs/pkgs/development/compilers/elm/README.md</filename>. To update Elm compiler, see
<filename>nixpkgs/pkgs/development/compilers/elm/README.md</filename>.
</para> </para>
<para> <para>
To package Elm applications, <link xlink:href="https://github.com/hercules-ci/elm2nix#elm2nix">read about elm2nix</link>. To package Elm applications,
<link xlink:href="https://github.com/hercules-ci/elm2nix#elm2nix">read about
elm2nix</link>.
</para> </para>
</section> </section>
<section xml:id="sec-shell-helpers"> <section xml:id="sec-shell-helpers">
<title>Interactive shell helpers</title> <title>Interactive shell helpers</title>

4
doc/platform-notes.xml
View File

@ -96,8 +96,8 @@
</programlisting> </programlisting>
<para> <para>
The package <literal>xcbuild</literal> can be used to build projects that The package <literal>xcbuild</literal> can be used to build projects that
really depend on Xcode. However, this replacement is not 100% really depend on Xcode. However, this replacement is not 100% compatible
compatible with Xcode and can occasionally cause issues. with Xcode and can occasionally cause issues.
</para> </para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>

4
doc/quick-start.xml
View File

@ -148,8 +148,8 @@ $ git add pkgs/development/libraries/libfoo/default.nix</screen>
<listitem> <listitem>
<para> <para>
You can use <command>nix-prefetch-url</command> You can use <command>nix-prefetch-url</command>
<replaceable>url</replaceable> to get the <replaceable>url</replaceable> to get the SHA-256 hash of source
SHA-256 hash of source distributions. There are similar commands as distributions. There are similar commands as
<command>nix-prefetch-git</command> and <command>nix-prefetch-git</command> and
<command>nix-prefetch-hg</command> available in <command>nix-prefetch-hg</command> available in
<literal>nix-prefetch-scripts</literal> package. <literal>nix-prefetch-scripts</literal> package.

14
doc/reviewing-contributions.xml
View File

@ -24,11 +24,13 @@
<para> <para>
The high change rate of Nixpkgs makes any pull request that remains open for The high change rate of Nixpkgs makes any pull request that remains open for
too long subject to conflicts that will require extra work from the submitter too long subject to conflicts that will require extra work from the submitter
or the merger. Reviewing pull requests in a timely manner and being responsive or the merger. Reviewing pull requests in a timely manner and being
to the comments is the key to avoid this issue. GitHub provides sort filters responsive to the comments is the key to avoid this issue. GitHub provides
that can be used to see the <link sort filters that can be used to see the
<link
xlink:href="https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc">most xlink:href="https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc">most
recently</link> and the <link recently</link> and the
<link
xlink:href="https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-asc">least xlink:href="https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-asc">least
recently</link> updated pull requests. We highly encourage looking at recently</link> updated pull requests. We highly encourage looking at
<link xlink:href="https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+review%3Anone+status%3Asuccess+-label%3A%222.status%3A+work-in-progress%22+no%3Aproject+no%3Aassignee+no%3Amilestone"> <link xlink:href="https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+review%3Anone+status%3Asuccess+-label%3A%222.status%3A+work-in-progress%22+no%3Aproject+no%3Aassignee+no%3Amilestone">
@ -609,8 +611,8 @@ policy.
create an issue or post on create an issue or post on
<link <link
xlink:href="https://discourse.nixos.org">Discourse</link> with xlink:href="https://discourse.nixos.org">Discourse</link> with
references of packages and modules they maintain so the maintainership can be references of packages and modules they maintain so the maintainership can
taken over by other contributors. be taken over by other contributors.
</para> </para>
</section> </section>
</chapter> </chapter>

450
doc/stdenv.xml
View File

@ -228,18 +228,17 @@ genericBuild
</para> </para>
<para> <para>
The extension of <envar>PATH</envar> with dependencies, alluded to The extension of <envar>PATH</envar> with dependencies, alluded to above,
above, proceeds according to the relative platforms alone. The proceeds according to the relative platforms alone. The process is carried
process is carried out only for dependencies whose host platform out only for dependencies whose host platform matches the new derivation's
matches the new derivation's build platform i.e. dependencies which build platform i.e. dependencies which run on the platform where the new
run on the platform where the new derivation will be built. derivation will be built.
<footnote xml:id="footnote-stdenv-native-dependencies-in-path"> <footnote xml:id="footnote-stdenv-native-dependencies-in-path">
<para> <para>
Currently, this means for native builds all dependencies are put Currently, this means for native builds all dependencies are put on the
on the <envar>PATH</envar>. But in the future that may not be the <envar>PATH</envar>. But in the future that may not be the case for sake
case for sake of matching cross: the platforms would be assumed of matching cross: the platforms would be assumed to be unique for native
to be unique for native and cross builds alike, so only the and cross builds alike, so only the <varname>depsBuild*</varname> and
<varname>depsBuild*</varname> and
<varname>nativeBuildInputs</varname> would be added to the <varname>nativeBuildInputs</varname> would be added to the
<envar>PATH</envar>. <envar>PATH</envar>.
</para> </para>
@ -252,9 +251,10 @@ genericBuild
<para> <para>
The dependency is propagated when it forces some of its other-transitive The dependency is propagated when it forces some of its other-transitive
(non-immediate) downstream dependencies to also take it on as an immediate (non-immediate) downstream dependencies to also take it on as an immediate
dependency. Nix itself already takes a package's transitive dependencies into dependency. Nix itself already takes a package's transitive dependencies
account, but this propagation ensures nixpkgs-specific infrastructure like into account, but this propagation ensures nixpkgs-specific infrastructure
setup hooks (mentioned above) also are run as if the propagated dependency. like setup hooks (mentioned above) also are run as if the propagated
dependency.
</para> </para>
<para> <para>
@ -270,9 +270,9 @@ genericBuild
described by the current dependency's platform offsets. This results in sort described by the current dependency's platform offsets. This results in sort
a transitive closure of the dependency relation, with the offsets being a transitive closure of the dependency relation, with the offsets being
approximately summed when two dependency links are combined. We also prune approximately summed when two dependency links are combined. We also prune
transitive dependencies whose combined offsets go out-of-bounds, which can be transitive dependencies whose combined offsets go out-of-bounds, which can
viewed as a filter over that transitive closure removing dependencies that be viewed as a filter over that transitive closure removing dependencies
are blatantly absurd. that are blatantly absurd.
</para> </para>
<para> <para>
@ -287,8 +287,8 @@ genericBuild
propagation logic. propagation logic.
</para> </para>
</footnote> </footnote>
They're confusing in very different ways so... hopefully if something doesn't They're confusing in very different ways so... hopefully if something
make sense in one presentation, it will in the other! doesn't make sense in one presentation, it will in the other!
<programlisting> <programlisting>
let mapOffset(h, t, i) = i + (if i &lt;= 0 then h else t - 1) let mapOffset(h, t, i) = i + (if i &lt;= 0 then h else t - 1)
@ -324,31 +324,31 @@ let f(h, h + 1, i) = i + (if i &lt;= 0 then h else (h + 1) - 1)
let f(h, h + 1, i) = i + (if i &lt;= 0 then h else h) let f(h, h + 1, i) = i + (if i &lt;= 0 then h else h)
let f(h, h + 1, i) = i + h let f(h, h + 1, i) = i + h
</programlisting> </programlisting>
This is where "sum-like" comes in from above: We can just sum all of the host This is where "sum-like" comes in from above: We can just sum all of the
offsets to get the host offset of the transitive dependency. The target host offsets to get the host offset of the transitive dependency. The target
offset is the transitive dependency is simply the host offset + 1, just as it offset is the transitive dependency is simply the host offset + 1, just as
was with the dependencies composed to make this transitive one; it can be it was with the dependencies composed to make this transitive one; it can be
ignored as it doesn't add any new information. ignored as it doesn't add any new information.
</para> </para>
<para> <para>
Because of the bounds checks, the uncommon cases are <literal>h = t</literal> Because of the bounds checks, the uncommon cases are <literal>h =
and <literal>h + 2 = t</literal>. In the former case, the motivation for t</literal> and <literal>h + 2 = t</literal>. In the former case, the
<function>mapOffset</function> is that since its host and target platforms motivation for <function>mapOffset</function> is that since its host and
are the same, no transitive dependency of it should be able to "discover" an target platforms are the same, no transitive dependency of it should be able
offset greater than its reduced target offsets. to "discover" an offset greater than its reduced target offsets.
<function>mapOffset</function> effectively "squashes" all its transitive <function>mapOffset</function> effectively "squashes" all its transitive
dependencies' offsets so that none will ever be greater than the target dependencies' offsets so that none will ever be greater than the target
offset of the original <literal>h = t</literal> package. In the other case, offset of the original <literal>h = t</literal> package. In the other case,
<literal>h + 1</literal> is skipped over between the host and target offsets. <literal>h + 1</literal> is skipped over between the host and target
Instead of squashing the offsets, we need to "rip" them apart so no offsets. Instead of squashing the offsets, we need to "rip" them apart so no
transitive dependencies' offset is that one. transitive dependencies' offset is that one.
</para> </para>
<para> <para>
Overall, the unifying theme here is that propagation shouldn't be introducing Overall, the unifying theme here is that propagation shouldn't be
transitive dependencies involving platforms the depending package is unaware introducing transitive dependencies involving platforms the depending
of. The offset bounds checking and definition of package is unaware of. The offset bounds checking and definition of
<function>mapOffset</function> together ensure that this is the case. <function>mapOffset</function> together ensure that this is the case.
Discovering a new offset is discovering a new platform, and since those Discovering a new offset is discovering a new platform, and since those
platforms weren't in the derivation "spec" of the needing package, they platforms weren't in the derivation "spec" of the needing package, they
@ -381,8 +381,8 @@ let f(h, h + 1, i) = i + h
Since these packages are able to be run at build-time, they are always Since these packages are able to be run at build-time, they are always
added to the <envar>PATH</envar>, as described above. But since these added to the <envar>PATH</envar>, as described above. But since these
packages are only guaranteed to be able to run then, they shouldn't packages are only guaranteed to be able to run then, they shouldn't
persist as run-time dependencies. This isn't currently enforced, but could persist as run-time dependencies. This isn't currently enforced, but
be in the future. could be in the future.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -396,10 +396,10 @@ let f(h, h + 1, i) = i + h
platform, and target platform is the new derivation's host platform. This platform, and target platform is the new derivation's host platform. This
means a <literal>-1</literal> host offset and <literal>0</literal> target means a <literal>-1</literal> host offset and <literal>0</literal> target
offset from the new derivation's platforms. These are programs and offset from the new derivation's platforms. These are programs and
libraries used at build-time that, if they are a compiler or similar tool, libraries used at build-time that, if they are a compiler or similar
produce code to run at run-time—i.e. tools used to build the new tool, produce code to run at run-time—i.e. tools used to build the new
derivation. If the dependency doesn't care about the target platform (i.e. derivation. If the dependency doesn't care about the target platform
isn't a compiler or similar tool), put it here, rather than in (i.e. isn't a compiler or similar tool), put it here, rather than in
<varname>depsBuildBuild</varname> or <varname>depsBuildTarget</varname>. <varname>depsBuildBuild</varname> or <varname>depsBuildTarget</varname>.
This could be called <varname>depsBuildHost</varname> but This could be called <varname>depsBuildHost</varname> but
<varname>nativeBuildInputs</varname> is used for historical continuity. <varname>nativeBuildInputs</varname> is used for historical continuity.
@ -407,8 +407,9 @@ let f(h, h + 1, i) = i + h
<para> <para>
Since these packages are able to be run at build-time, they are added to Since these packages are able to be run at build-time, they are added to
the <envar>PATH</envar>, as described above. But since these packages are the <envar>PATH</envar>, as described above. But since these packages are
only guaranteed to be able to run then, they shouldn't persist as run-time only guaranteed to be able to run then, they shouldn't persist as
dependencies. This isn't currently enforced, but could be in the future. run-time dependencies. This isn't currently enforced, but could be in the
future.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -421,33 +422,36 @@ let f(h, h + 1, i) = i + h
A list of dependencies whose host platform is the new derivation's build A list of dependencies whose host platform is the new derivation's build
platform, and target platform is the new derivation's target platform. platform, and target platform is the new derivation's target platform.
This means a <literal>-1</literal> host offset and <literal>1</literal> This means a <literal>-1</literal> host offset and <literal>1</literal>
target offset from the new derivation's platforms. These are programs used target offset from the new derivation's platforms. These are programs
at build time that produce code to run with code produced by the depending used at build time that produce code to run with code produced by the
package. Most commonly, these are tools used to build the runtime or depending package. Most commonly, these are tools used to build the
standard library that the currently-being-built compiler will inject into runtime or standard library that the currently-being-built compiler will
any code it compiles. In many cases, the currently-being-built-compiler is inject into any code it compiles. In many cases, the
itself employed for that task, but when that compiler won't run (i.e. its currently-being-built-compiler is itself employed for that task, but when
build and host platform differ) this is not possible. Other times, the that compiler won't run (i.e. its build and host platform differ) this is
compiler relies on some other tool, like binutils, that is always built not possible. Other times, the compiler relies on some other tool, like
separately so that the dependency is unconditional. binutils, that is always built separately so that the dependency is
unconditional.
</para> </para>
<para> <para>
This is a somewhat confusing concept to wrap one’s head around, and for This is a somewhat confusing concept to wrap one’s head around, and for
good reason. As the only dependency type where the platform offsets are good reason. As the only dependency type where the platform offsets are
not adjacent integers, it requires thinking of a bootstrapping stage not adjacent integers, it requires thinking of a bootstrapping stage
<emphasis>two</emphasis> away from the current one. It and its use-case go <emphasis>two</emphasis> away from the current one. It and its use-case
hand in hand and are both considered poor form: try to not need this sort go hand in hand and are both considered poor form: try to not need this
of dependency, and try to avoid building standard libraries and runtimes sort of dependency, and try to avoid building standard libraries and
in the same derivation as the compiler produces code using them. Instead runtimes in the same derivation as the compiler produces code using them.
strive to build those like a normal library, using the newly-built Instead strive to build those like a normal library, using the
compiler just as a normal library would. In short, do not use this newly-built compiler just as a normal library would. In short, do not use
attribute unless you are packaging a compiler and are sure it is needed. this attribute unless you are packaging a compiler and are sure it is
needed.
</para> </para>
<para> <para>
Since these packages are able to run at build time, they are added to the Since these packages are able to run at build time, they are added to the
<envar>PATH</envar>, as described above. But since these packages are only <envar>PATH</envar>, as described above. But since these packages are
guaranteed to be able to run then, they shouldn't persist as run-time only guaranteed to be able to run then, they shouldn't persist as
dependencies. This isn't currently enforced, but could be in the future. run-time dependencies. This isn't currently enforced, but could be in the
future.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -462,11 +466,11 @@ let f(h, h + 1, i) = i + h
and <literal>0</literal> target offset from the new derivation's host and <literal>0</literal> target offset from the new derivation's host
platform. These are packages used at run-time to generate code also used platform. These are packages used at run-time to generate code also used
at run-time. In practice, this would usually be tools used by compilers at run-time. In practice, this would usually be tools used by compilers
for macros or a metaprogramming system, or libraries used by the macros or for macros or a metaprogramming system, or libraries used by the macros
metaprogramming code itself. It's always preferable to use a or metaprogramming code itself. It's always preferable to use a
<varname>depsBuildBuild</varname> dependency in the derivation being built <varname>depsBuildBuild</varname> dependency in the derivation being
over a <varname>depsHostHost</varname> on the tool doing the building for built over a <varname>depsHostHost</varname> on the tool doing the
this purpose. building for this purpose.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -481,8 +485,8 @@ let f(h, h + 1, i) = i + h
<literal>1</literal> target offset from the new derivation's host <literal>1</literal> target offset from the new derivation's host
platform. This would be called <varname>depsHostTarget</varname> but for platform. This would be called <varname>depsHostTarget</varname> but for
historical continuity. If the dependency doesn't care about the target historical continuity. If the dependency doesn't care about the target
platform (i.e. isn't a compiler or similar tool), put it here, rather than platform (i.e. isn't a compiler or similar tool), put it here, rather
in <varname>depsBuildBuild</varname>. than in <varname>depsBuildBuild</varname>.
</para> </para>
<para> <para>
These are often programs and libraries used by the new derivation at These are often programs and libraries used by the new derivation at
@ -664,10 +668,11 @@ passthru = {
<literal>hello.baz.value1</literal>. We don't specify any usage or schema <literal>hello.baz.value1</literal>. We don't specify any usage or schema
of <literal>passthru</literal> - it is meant for values that would be of <literal>passthru</literal> - it is meant for values that would be
useful outside the derivation in other parts of a Nix expression (e.g. in useful outside the derivation in other parts of a Nix expression (e.g. in
other derivations). An example would be to convey some specific dependency other derivations). An example would be to convey some specific
of your derivation which contains a program with plugins support. Later, dependency of your derivation which contains a program with plugins
others who make derivations with plugins can use passed-through dependency support. Later, others who make derivations with plugins can use
to ensure that their plugin would be binary-compatible with built program. passed-through dependency to ensure that their plugin would be
binary-compatible with built program.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -677,9 +682,9 @@ passthru = {
</term> </term>
<listitem> <listitem>
<para> <para>
A script to be run by <filename>maintainers/scripts/update.nix</filename> when A script to be run by <filename>maintainers/scripts/update.nix</filename>
the package is matched. It needs to be an executable file, either on the file when the package is matched. It needs to be an executable file, either on
system: the file system:
<programlisting> <programlisting>
passthru.updateScript = ./update.sh; passthru.updateScript = ./update.sh;
</programlisting> </programlisting>
@ -695,16 +700,24 @@ passthru.updateScript = writeScript "update-zoom-us" ''
update-source-version zoom-us "$version" update-source-version zoom-us "$version"
''; '';
</programlisting> </programlisting>
The attribute can also contain a list, a script followed by arguments to be passed to it: The attribute can also contain a list, a script followed by arguments to
be passed to it:
<programlisting> <programlisting>
passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]; passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ];
</programlisting> </programlisting>
Note that the update scripts will be run in parallel by default; you should avoid running <command>git commit</command> or any other commands that cannot handle that. Note that the update scripts will be run in parallel by default; you
should avoid running <command>git commit</command> or any other commands
that cannot handle that.
</para> </para>
<para> <para>
For information about how to run the updates, execute For information about how to run the updates, execute
<cmdsynopsis><command>nix-shell</command> <arg>maintainers/scripts/update.nix</arg></cmdsynopsis>. <cmdsynopsis>
<command>nix-shell</command>
<arg>
maintainers/scripts/update.nix
</arg>
</cmdsynopsis>
.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -1178,8 +1191,8 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
By default, when cross compiling, the configure script has By default, when cross compiling, the configure script has
<option>--build=...</option> and <option>--host=...</option> passed. <option>--build=...</option> and <option>--host=...</option> passed.
Packages can instead pass <literal>[ "build" "host" "target" ]</literal> Packages can instead pass <literal>[ "build" "host" "target" ]</literal>
or a subset to control exactly which platform flags are passed. Compilers or a subset to control exactly which platform flags are passed.
and other tools can use this to also pass the target platform. Compilers and other tools can use this to also pass the target platform.
<footnote xml:id="footnote-stdenv-build-time-guessing-impurity"> <footnote xml:id="footnote-stdenv-build-time-guessing-impurity">
<para> <para>
Eventually these will be passed building natively as well, to improve Eventually these will be passed building natively as well, to improve
@ -1694,10 +1707,11 @@ installTargets = "install-bin install-doc";</programlisting>
</term> </term>
<listitem> <listitem>
<para> <para>
A package can export a <link linkend="ssec-setup-hooks">setup hook</link> A package can export a <link linkend="ssec-setup-hooks">setup
by setting this variable. The setup hook, if defined, is copied to hook</link> by setting this variable. The setup hook, if defined, is
<filename>$out/nix-support/setup-hook</filename>. Environment variables copied to <filename>$out/nix-support/setup-hook</filename>. Environment
are then substituted in it using <function variables are then substituted in it using
<function
linkend="fun-substituteAll">substituteAll</function>. linkend="fun-substituteAll">substituteAll</function>.
</para> </para>
</listitem> </listitem>
@ -1812,8 +1826,8 @@ set debug-file-directory ~/.nix-profile/lib/debug
<listitem> <listitem>
<para> <para>
A list of dependencies used by the phase. This gets included in A list of dependencies used by the phase. This gets included in
<varname>nativeBuildInputs</varname> when <varname>doInstallCheck</varname> is <varname>nativeBuildInputs</varname> when
set. <varname>doInstallCheck</varname> is set.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -2160,10 +2174,11 @@ someVar=$(stripHash $name)
dependency derivation is already built just the same—depending is just dependency derivation is already built just the same—depending is just
needing something to exist, and needing is idempotent. However, a dependency needing something to exist, and needing is idempotent. However, a dependency
specified twice will have its setup hook run twice, and that could easily specified twice will have its setup hook run twice, and that could easily
change the build environment (though a well-written setup hook will therefore change the build environment (though a well-written setup hook will
strive to be idempotent so this is in fact not observable). More broadly, therefore strive to be idempotent so this is in fact not observable). More
setup hooks are anti-modular in that multiple dependencies, whether the same broadly, setup hooks are anti-modular in that multiple dependencies, whether
or different, should not interfere and yet their setup hooks may well do so. the same or different, should not interfere and yet their setup hooks may
well do so.
</para> </para>
<para> <para>
@ -2185,11 +2200,12 @@ someVar=$(stripHash $name)
Returning to the C compiler wrapper example, if the wrapper itself is an Returning to the C compiler wrapper example, if the wrapper itself is an
<literal>n</literal> dependency, then it only wants to accumulate flags from <literal>n</literal> dependency, then it only wants to accumulate flags from
<literal>n + 1</literal> dependencies, as only those ones match the <literal>n + 1</literal> dependencies, as only those ones match the
compiler's target platform. The <envar>hostOffset</envar> variable is defined compiler's target platform. The <envar>hostOffset</envar> variable is
with the current dependency's host offset <envar>targetOffset</envar> with defined with the current dependency's host offset
its target offset, before its setup hook is sourced. Additionally, since most <envar>targetOffset</envar> with its target offset, before its setup hook is
environment hooks don't care about the target platform, that means the setup sourced. Additionally, since most environment hooks don't care about the
hook can append to the right bash array by doing something like target platform, that means the setup hook can append to the right bash
array by doing something like
<programlisting language="bash"> <programlisting language="bash">
addEnvHooks "$hostOffset" myBashFunction addEnvHooks "$hostOffset" myBashFunction
</programlisting> </programlisting>
@ -2204,11 +2220,10 @@ addEnvHooks "$hostOffset" myBashFunction
</para> </para>
<para> <para>
First, let’s cover some setup hooks that are part of Nixpkgs First, let’s cover some setup hooks that are part of Nixpkgs default
default stdenv. This means that they are run for every package stdenv. This means that they are run for every package built using
built using <function>stdenv.mkDerivation</function>. Some of <function>stdenv.mkDerivation</function>. Some of these are platform
these are platform specific, so they may run on Linux but not specific, so they may run on Linux but not Darwin or vice-versa.
Darwin or vice-versa.
<variablelist> <variablelist>
<varlistentry> <varlistentry>
<term> <term>
@ -2217,10 +2232,9 @@ addEnvHooks "$hostOffset" myBashFunction
<listitem> <listitem>
<para> <para>
This setup hook moves any installed documentation to the This setup hook moves any installed documentation to the
<literal>/share</literal> subdirectory directory. This includes <literal>/share</literal> subdirectory directory. This includes the man,
the man, doc and info directories. This is needed for legacy doc and info directories. This is needed for legacy programs that do not
programs that do not know how to use the know how to use the <literal>share</literal> subdirectory.
<literal>share</literal> subdirectory.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -2230,9 +2244,9 @@ addEnvHooks "$hostOffset" myBashFunction
</term> </term>
<listitem> <listitem>
<para> <para>
This setup hook compresses any man pages that have been This setup hook compresses any man pages that have been installed. The
installed. The compression is done using the gzip program. This compression is done using the gzip program. This helps to reduce the
helps to reduce the installed size of packages. installed size of packages.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -2242,10 +2256,9 @@ addEnvHooks "$hostOffset" myBashFunction
</term> </term>
<listitem> <listitem>
<para> <para>
This runs the strip command on installed binaries and This runs the strip command on installed binaries and libraries. This
libraries. This removes unnecessary information like debug removes unnecessary information like debug symbols when they are not
symbols when they are not needed. This also helps to reduce the needed. This also helps to reduce the installed size of packages.
installed size of packages.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -2255,13 +2268,12 @@ addEnvHooks "$hostOffset" myBashFunction
</term> </term>
<listitem> <listitem>
<para> <para>
This setup hook patches installed scripts to use the full path This setup hook patches installed scripts to use the full path to the
to the shebang interpreter. A shebang interpreter is the first shebang interpreter. A shebang interpreter is the first commented line
commented line of a script telling the operating system which of a script telling the operating system which program will run the
program will run the script (e.g <literal>#!/bin/bash</literal>). In script (e.g <literal>#!/bin/bash</literal>). In Nix, we want an exact
Nix, we want an exact path to that interpreter to be used. This path to that interpreter to be used. This often replaces
often replaces <literal>/bin/sh</literal> with a path in the <literal>/bin/sh</literal> with a path in the Nix store.
Nix store.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -2271,10 +2283,10 @@ addEnvHooks "$hostOffset" myBashFunction
</term> </term>
<listitem> <listitem>
<para> <para>
This verifies that no references are left from the install This verifies that no references are left from the install binaries to
binaries to the directory used to build those binaries. This the directory used to build those binaries. This ensures that the
ensures that the binaries do not need things outside the Nix binaries do not need things outside the Nix store. This is currently
store. This is currently supported in Linux only. supported in Linux only.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -2284,12 +2296,12 @@ addEnvHooks "$hostOffset" myBashFunction
</term> </term>
<listitem> <listitem>
<para> <para>
This setup hook adds configure flags that tell packages to This setup hook adds configure flags that tell packages to install files
install files into any one of the proper outputs listed in into any one of the proper outputs listed in <literal>outputs</literal>.
<literal>outputs</literal>. This behavior can be turned off by setting This behavior can be turned off by setting
<literal>setOutputFlags</literal> to false in the derivation <literal>setOutputFlags</literal> to false in the derivation
environment. See <xref linkend="chap-multiple-output"/> for environment. See <xref linkend="chap-multiple-output"/> for more
more information. information.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -2299,9 +2311,9 @@ addEnvHooks "$hostOffset" myBashFunction
</term> </term>
<listitem> <listitem>
<para> <para>
This setup hook moves any binaries installed in the sbin This setup hook moves any binaries installed in the sbin subdirectory
subdirectory into bin. In addition, a link is provided from into bin. In addition, a link is provided from sbin to bin for
sbin to bin for compatibility. compatibility.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -2311,9 +2323,9 @@ addEnvHooks "$hostOffset" myBashFunction
</term> </term>
<listitem> <listitem>
<para> <para>
This setup hook moves any libraries installed in the lib64 This setup hook moves any libraries installed in the lib64 subdirectory
subdirectory into lib. In addition, a link is provided from into lib. In addition, a link is provided from lib64 to lib for
lib64 to lib for compatibility. compatibility.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -2323,8 +2335,8 @@ addEnvHooks "$hostOffset" myBashFunction
</term> </term>
<listitem> <listitem>
<para> <para>
This sets <literal>SOURCE_DATE_EPOCH</literal> to the This sets <literal>SOURCE_DATE_EPOCH</literal> to the modification time
modification time of the most recent file. of the most recent file.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -2335,19 +2347,19 @@ addEnvHooks "$hostOffset" myBashFunction
<listitem> <listitem>
<para> <para>
The Bintools Wrapper wraps the binary utilities for a bunch of The Bintools Wrapper wraps the binary utilities for a bunch of
miscellaneous purposes. These are GNU Binutils when targetting Linux, and miscellaneous purposes. These are GNU Binutils when targetting Linux,
a mix of cctools and GNU binutils for Darwin. [The "Bintools" name is and a mix of cctools and GNU binutils for Darwin. [The "Bintools" name
supposed to be a compromise between "Binutils" and "cctools" not denoting is supposed to be a compromise between "Binutils" and "cctools" not
any specific implementation.] Specifically, the underlying bintools denoting any specific implementation.] Specifically, the underlying
package, and a C standard library (glibc or Darwin's libSystem, just for bintools package, and a C standard library (glibc or Darwin's libSystem,
the dynamic loader) are all fed in, and dependency finding, hardening just for the dynamic loader) are all fed in, and dependency finding,
(see below), and purity checks for each are handled by the Bintools hardening (see below), and purity checks for each are handled by the
Wrapper. Packages typically depend on CC Wrapper, which in turn (at run Bintools Wrapper. Packages typically depend on CC Wrapper, which in turn
time) depends on the Bintools Wrapper. (at run time) depends on the Bintools Wrapper.
</para> </para>
<para> <para>
The Bintools Wrapper was only just recently split off from CC Wrapper, so The Bintools Wrapper was only just recently split off from CC Wrapper,
the division of labor is still being worked out. For example, it so the division of labor is still being worked out. For example, it
shouldn't care about about the C standard library, but just take a shouldn't care about about the C standard library, but just take a
derivation with the dynamic loader (which happens to be the glibc on derivation with the dynamic loader (which happens to be the glibc on
linux). Dependency finding however is a task both wrappers will continue linux). Dependency finding however is a task both wrappers will continue
@ -2357,11 +2369,12 @@ addEnvHooks "$hostOffset" myBashFunction
<varname>nativeBuildInputs</varname>) in environment variables. The <varname>nativeBuildInputs</varname>) in environment variables. The
Bintools Wrapper's setup hook causes any <filename>lib</filename> and Bintools Wrapper's setup hook causes any <filename>lib</filename> and
<filename>lib64</filename> subdirectories to be added to <filename>lib64</filename> subdirectories to be added to
<envar>NIX_LDFLAGS</envar>. Since the CC Wrapper and the Bintools Wrapper <envar>NIX_LDFLAGS</envar>. Since the CC Wrapper and the Bintools
use the same strategy, most of the Bintools Wrapper code is sparsely Wrapper use the same strategy, most of the Bintools Wrapper code is
commented and refers to the CC Wrapper. But the CC Wrapper's code, by sparsely commented and refers to the CC Wrapper. But the CC Wrapper's
contrast, has quite lengthy comments. The Bintools Wrapper merely cites code, by contrast, has quite lengthy comments. The Bintools Wrapper
those, rather than repeating them, to avoid falling out of sync. merely cites those, rather than repeating them, to avoid falling out of
sync.
</para> </para>
<para> <para>
A final task of the setup hook is defining a number of standard A final task of the setup hook is defining a number of standard
@ -2370,8 +2383,8 @@ addEnvHooks "$hostOffset" myBashFunction
under the assumption that the Bintools Wrapper's binaries will be on the under the assumption that the Bintools Wrapper's binaries will be on the
path. Firstly, this helps poorly-written packages, e.g. ones that look path. Firstly, this helps poorly-written packages, e.g. ones that look
for just <command>gcc</command> when <envar>CC</envar> isn't defined yet for just <command>gcc</command> when <envar>CC</envar> isn't defined yet
<command>clang</command> is to be used. Secondly, this helps packages not <command>clang</command> is to be used. Secondly, this helps packages
get confused when cross-compiling, in which case multiple Bintools not get confused when cross-compiling, in which case multiple Bintools
Wrappers may simultaneously be in use. Wrappers may simultaneously be in use.
<footnote xml:id="footnote-stdenv-per-platform-wrapper"> <footnote xml:id="footnote-stdenv-per-platform-wrapper">
<para> <para>
@ -2387,16 +2400,16 @@ addEnvHooks "$hostOffset" myBashFunction
Wrappers, properly disambiguating them. Wrappers, properly disambiguating them.
</para> </para>
<para> <para>
A problem with this final task is that the Bintools Wrapper is honest and A problem with this final task is that the Bintools Wrapper is honest
defines <envar>LD</envar> as <command>ld</command>. Most packages, and defines <envar>LD</envar> as <command>ld</command>. Most packages,
however, firstly use the C compiler for linking, secondly use however, firstly use the C compiler for linking, secondly use
<envar>LD</envar> anyways, defining it as the C compiler, and thirdly, <envar>LD</envar> anyways, defining it as the C compiler, and thirdly,
only so define <envar>LD</envar> when it is undefined as a fallback. This only so define <envar>LD</envar> when it is undefined as a fallback.
triple-threat means Bintools Wrapper will break those packages, as LD is This triple-threat means Bintools Wrapper will break those packages, as
already defined as the actual linker which the package won't override yet LD is already defined as the actual linker which the package won't
doesn't want to use. The workaround is to define, just for the override yet doesn't want to use. The workaround is to define, just for
problematic package, <envar>LD</envar> as the C compiler. A good way to the problematic package, <envar>LD</envar> as the C compiler. A good way
do this would be <command>preConfigure = "LD=$CC"</command>. to do this would be <command>preConfigure = "LD=$CC"</command>.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -2406,13 +2419,13 @@ addEnvHooks "$hostOffset" myBashFunction
</term> </term>
<listitem> <listitem>
<para> <para>
The CC Wrapper wraps a C toolchain for a bunch of miscellaneous purposes. The CC Wrapper wraps a C toolchain for a bunch of miscellaneous
Specifically, a C compiler (GCC or Clang), wrapped binary tools, and a C purposes. Specifically, a C compiler (GCC or Clang), wrapped binary
standard library (glibc or Darwin's libSystem, just for the dynamic tools, and a C standard library (glibc or Darwin's libSystem, just for
loader) are all fed in, and dependency finding, hardening (see below), the dynamic loader) are all fed in, and dependency finding, hardening
and purity checks for each are handled by the CC Wrapper. Packages (see below), and purity checks for each are handled by the CC Wrapper.
typically depend on the CC Wrapper, which in turn (at run-time) depends Packages typically depend on the CC Wrapper, which in turn (at run-time)
on the Bintools Wrapper. depends on the Bintools Wrapper.
</para> </para>
<para> <para>
Dependency finding is undoubtedly the main task of the CC Wrapper. This Dependency finding is undoubtedly the main task of the CC Wrapper. This
@ -2438,10 +2451,9 @@ addEnvHooks "$hostOffset" myBashFunction
</para> </para>
<para> <para>
Here are some more packages that provide a setup hook. Since the Here are some more packages that provide a setup hook. Since the list of
list of hooks is extensible, this is not an exhaustive list the hooks is extensible, this is not an exhaustive list the mechanism is only to
mechanism is only to be used as a last resort, it might cover most be used as a last resort, it might cover most uses.
uses.
<variablelist> <variablelist>
<varlistentry> <varlistentry>
<term> <term>
@ -2499,11 +2511,11 @@ addEnvHooks "$hostOffset" myBashFunction
<listitem> <listitem>
<para> <para>
The <varname>autoreconfHook</varname> derivation adds The <varname>autoreconfHook</varname> derivation adds
<varname>autoreconfPhase</varname>, which runs autoreconf, libtoolize and <varname>autoreconfPhase</varname>, which runs autoreconf, libtoolize
automake, essentially preparing the configure script in autotools-based and automake, essentially preparing the configure script in
builds. Most autotools-based packages come with the configure script autotools-based builds. Most autotools-based packages come with the
pre-generated, but this hook is necessary for a few packages and when you configure script pre-generated, but this hook is necessary for a few
need to patch the package’s configure scripts. packages and when you need to patch the package’s configure scripts.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -2547,9 +2559,9 @@ addEnvHooks "$hostOffset" myBashFunction
</term> </term>
<listitem> <listitem>
<para> <para>
Exports <envar>GDK_PIXBUF_MODULE_FILE</envar> environment variable to the Exports <envar>GDK_PIXBUF_MODULE_FILE</envar> environment variable to
builder. Add librsvg package to <varname>buildInputs</varname> to get svg the builder. Add librsvg package to <varname>buildInputs</varname> to
support. get svg support.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -2595,14 +2607,13 @@ addEnvHooks "$hostOffset" myBashFunction
<para> <para>
This is useful for programs that use <citerefentry> This is useful for programs that use <citerefentry>
<refentrytitle>dlopen</refentrytitle> <refentrytitle>dlopen</refentrytitle>
<manvolnum>3</manvolnum> <manvolnum>3</manvolnum> </citerefentry> to load libraries at runtime.
</citerefentry> to load libraries at runtime.
</para> </para>
<para> <para>
In certain situations you may want to run the main command In certain situations you may want to run the main command
(<command>autoPatchelf</command>) of the setup hook on a file or a set (<command>autoPatchelf</command>) of the setup hook on a file or a set
of directories instead of unconditionally patching all outputs. This of directories instead of unconditionally patching all outputs. This can
can be done by setting the <envar>dontAutoPatchelf</envar> environment be done by setting the <envar>dontAutoPatchelf</envar> environment
variable to a non-empty value. variable to a non-empty value.
</para> </para>
<para> <para>
@ -2619,22 +2630,22 @@ addEnvHooks "$hostOffset" myBashFunction
<listitem> <listitem>
<para> <para>
This hook will make a build pause instead of stopping when a failure This hook will make a build pause instead of stopping when a failure
happens. It prevents nix from cleaning up the build environment immediately and happens. It prevents nix from cleaning up the build environment
allows the user to attach to a build environment using the immediately and allows the user to attach to a build environment using
<command>cntr</command> command. Upon build error it will print the <command>cntr</command> command. Upon build error it will print
instructions on how to use <command>cntr</command>. Installing instructions on how to use <command>cntr</command>. Installing cntr and
cntr and running the command will provide shell access to the build running the command will provide shell access to the build sandbox of
sandbox of failed build. At <filename>/var/lib/cntr</filename> the failed build. At <filename>/var/lib/cntr</filename> the sandboxed
sandboxed filesystem is mounted. All commands and files of the system are filesystem is mounted. All commands and files of the system are still
still accessible within the shell. To execute commands from the sandbox accessible within the shell. To execute commands from the sandbox use
use the cntr exec subcommand. Note that <command>cntr</command> also the cntr exec subcommand. Note that <command>cntr</command> also needs
needs to be executed on the machine that is doing the build, which might to be executed on the machine that is doing the build, which might not
not be the case when remote builders are enabled. be the case when remote builders are enabled. <command>cntr</command> is
<command>cntr</command> is only supported on Linux-based platforms. To only supported on Linux-based platforms. To use it first add
use it first add <literal>cntr</literal> to your <literal>cntr</literal> to your
<literal>environment.systemPackages</literal> on NixOS or alternatively to <literal>environment.systemPackages</literal> on NixOS or alternatively
the root user on non-NixOS systems. Then in the package that is supposed to the root user on non-NixOS systems. Then in the package that is
to be inspected, add <literal>breakpointHook</literal> to supposed to be inspected, add <literal>breakpointHook</literal> to
<literal>nativeBuildInputs</literal>. <literal>nativeBuildInputs</literal>.
<programlisting> <programlisting>
nativeBuildInputs = [ breakpointHook ]; nativeBuildInputs = [ breakpointHook ];
@ -2650,14 +2661,13 @@ addEnvHooks "$hostOffset" myBashFunction
</term> </term>
<listitem> <listitem>
<para> <para>
A few libraries automatically add to A few libraries automatically add to <literal>NIX_LDFLAGS</literal>
<literal>NIX_LDFLAGS</literal> their library, making their their library, making their symbols automatically available to the
symbols automatically available to the linker. This includes linker. This includes libiconv and libintl (gettext). This is done to
libiconv and libintl (gettext). This is done to provide provide compatibility between GNU Linux, where libiconv and libintl are
compatibility between GNU Linux, where libiconv and libintl bundled in, and other systems where that might not be the case.
are bundled in, and other systems where that might not be the Sometimes, this behavior is not desired. To disable this behavior, set
case. Sometimes, this behavior is not desired. To disable <literal>dontAddExtraLibs</literal>.
this behavior, set <literal>dontAddExtraLibs</literal>.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -2668,15 +2678,15 @@ addEnvHooks "$hostOffset" myBashFunction
<listitem> <listitem>
<para> <para>
Overrides the default configure phase to run the CMake command. By Overrides the default configure phase to run the CMake command. By
default, we use the Make generator of CMake. In default, we use the Make generator of CMake. In addition, dependencies
addition, dependencies are added automatically to CMAKE_PREFIX_PATH so are added automatically to CMAKE_PREFIX_PATH so that packages are
that packages are correctly detected by CMake. Some additional flags correctly detected by CMake. Some additional flags are passed in to give
are passed in to give similar behavior to configure-based packages. You similar behavior to configure-based packages. You can disable this
can disable this hook’s behavior by setting configurePhase to a custom hook’s behavior by setting configurePhase to a custom value, or by
value, or by setting dontUseCmakeConfigure. cmakeFlags controls flags setting dontUseCmakeConfigure. cmakeFlags controls flags passed only to
passed only to CMake. By default, parallel building is enabled as CMake CMake. By default, parallel building is enabled as CMake supports
supports parallel building almost everywhere. When Ninja is also in parallel building almost everywhere. When Ninja is also in use, CMake
use, CMake will detect that and use the ninja generator. will detect that and use the ninja generator.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -2689,8 +2699,8 @@ addEnvHooks "$hostOffset" myBashFunction
Overrides the build and install phases to run the “xcbuild” command. Overrides the build and install phases to run the “xcbuild” command.
This hook is needed when a project only comes with build files for the This hook is needed when a project only comes with build files for the
XCode build system. You can disable this behavior by setting buildPhase XCode build system. You can disable this behavior by setting buildPhase
and configurePhase to a custom value. xcbuildFlags controls flags and configurePhase to a custom value. xcbuildFlags controls flags passed
passed only to xcbuild. only to xcbuild.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -2703,8 +2713,8 @@ addEnvHooks "$hostOffset" myBashFunction
Overrides the configure phase to run meson to generate Ninja files. You Overrides the configure phase to run meson to generate Ninja files. You
can disable this behavior by setting configurePhase to a custom value, can disable this behavior by setting configurePhase to a custom value,
or by setting dontUseMesonConfigure. To run these files, you should or by setting dontUseMesonConfigure. To run these files, you should
accompany meson with ninja. mesonFlags controls only the flags passed accompany meson with ninja. mesonFlags controls only the flags passed to
to meson. By default, parallel building is enabled as Meson supports meson. By default, parallel building is enabled as Meson supports
parallel building almost everywhere. parallel building almost everywhere.
</para> </para>
</listitem> </listitem>