colin/nixpkgs
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

manual: Fix typos

Browse Source 
Thanks @matthewbauer!

Co-Authored-By: Ericson2314 <git@JohnEricson.me>
This commit is contained in:
John Ericson 2019-03-25 17:50:13 -04:00 committed by GitHub
parent 5e5266f83f
commit 8ba4db0f11
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 18 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
doc/cross-compilation.xml
View File

@ -259,8 +259,8 @@
machine-code-producing tools, we're done. And indeed machine-code-producing tools, we're done. And indeed
<varname>buildInputs</varname> and <varname>nativeBuildInputs</varname> <varname>buildInputs</varname> and <varname>nativeBuildInputs</varname>
have covered these simpler build-time and run-time (respectively) changes have covered these simpler build-time and run-time (respectively) changes
for many years. But if the depedency does produce machine code, we might for many years. But if the dependency does produce machine code, we might
need to worry about it's target platform too. In principle, that target need to worry about its target platform too. In principle, that target
platform might be any of the depending package's build, host, or target platform might be any of the depending package's build, host, or target
platforms, but we prohibit dependencies from a "later" platform to an platforms, but we prohibit dependencies from a "later" platform to an
earlier platform to limit confusion because we've never seen a legitimate earlier platform to limit confusion because we've never seen a legitimate
@ -270,7 +270,7 @@
<para> <para>
Finally, if the depending package is a compiler or other Finally, if the depending package is a compiler or other
machine-code-producing tool, it might need dependencies that run at "emit machine-code-producing tool, it might need dependencies that run at "emit
time". This is for compilers that (regrettably) insist on being in built time". This is for compilers that (regrettably) insist on being built
together with their source langauges' standard libraries. Assuming build != together with their source langauges' standard libraries. Assuming build !=
host != target, a run-time dependency of the standard library cannot be run host != target, a run-time dependency of the standard library cannot be run
at the compiler's build time or run time, but only at the run time of code at the compiler's build time or run time, but only at the run time of code
@ -485,9 +485,9 @@ nix-build &lt;nixpkgs&gt; --arg crossSystem '{ config = "&lt;arch&gt;-&lt;os&gt;
<xref <xref
linkend="ssec-cross-dependency-categorization"/> are specified as linkend="ssec-cross-dependency-categorization"/> are specified as
lists of derivations given to <varname>mkDerivation</varname>, as lists of derivations given to <varname>mkDerivation</varname>, as
documented in <xref linkend="ssec-stdenv-dependencies"/>. In short, the documented in <xref linkend="ssec-stdenv-dependencies"/>. In short,
each list of dependencies for "host → target" of "foo → bar" is called each list of dependencies for "host → target" of "foo → bar" is called
<varname>depsFooBar</varname>, with the exceptions for backwards <varname>depsFooBar</varname>, with exceptions for backwards
compatibility that <varname>depsBuildHost</varname> is instead called compatibility that <varname>depsBuildHost</varname> is instead called
<varname>nativeBuildInputs</varname> and <varname>depsHostTarget</varname> <varname>nativeBuildInputs</varname> and <varname>depsHostTarget</varname>
is instead called <varname>buildInputs</varname>. Nixpkgs is now structured is instead called <varname>buildInputs</varname>. Nixpkgs is now structured
@ -501,13 +501,13 @@ nix-build &lt;nixpkgs&gt; --arg crossSystem '{ config = "&lt;arch&gt;-&lt;os&gt;
</para> </para>
<para> <para>
Now, for most of Nixpkgs's history, there was no Now, for most of Nixpkgs's history, there were no
<varname>pkgsFooBar</varname> attributes, and most packages have not been <varname>pkgsFooBar</varname> attributes, and most packages have not been
refactored to use it explicitly. Prior to those, there were just refactored to use it explicitly. Prior to those, there were just
<varname>buildPackages</varname>, <varname>pkgs</varname>, and <varname>buildPackages</varname>, <varname>pkgs</varname>, and
<varname>targetPackages</varname>. Those are now redefined as aliases to <varname>targetPackages</varname>. Those are now redefined as aliases to
<varname>pkgsBuildHost</varname>, <varname>pkgsHostTarget</varname>, and <varname>pkgsBuildHost</varname>, <varname>pkgsHostTarget</varname>, and
<varname>pkgsTargetTarget</varname>. It is fine, indeed if anything <varname>pkgsTargetTarget</varname>. It is acceptable, even
recommended, to use them for libraries to show that the host platform is recommended, to use them for libraries to show that the host platform is
irrelevant. irrelevant.
</para> </para>
@ -523,12 +523,12 @@ nix-build &lt;nixpkgs&gt; --arg crossSystem '{ config = "&lt;arch&gt;-&lt;os&gt;
their dependencies into the multiple lists described above. And indeed, their dependencies into the multiple lists described above. And indeed,
asking that users both sort their dependencies, <emphasis>and</emphasis> asking that users both sort their dependencies, <emphasis>and</emphasis>
take them from the right attribute set, is both too onerous and redundant, take them from the right attribute set, is both too onerous and redundant,
so the recommend approach (for now) is to continue just categorizing by so the recommended approach (for now) is to continue just categorizing by
list and not using an explicit package set. list and not using an explicit package set.
</para> </para>
<para> <para>
No make this work, we "splice" together the six To make this work, we "splice" together the six
<varname>pkgsFooBar</varname> package sets and have <varname>pkgsFooBar</varname> package sets and have
<varname>callPackage</varname> actually take its arguments from that. This <varname>callPackage</varname> actually take its arguments from that. This
is currently implemented in <filename>pkgs/top-level/splice.nix</filename>. is currently implemented in <filename>pkgs/top-level/splice.nix</filename>.
@ -550,7 +550,7 @@ nix-build &lt;nixpkgs&gt; --arg crossSystem '{ config = "&lt;arch&gt;-&lt;os&gt;
<filename>pkgs/top-level/stage.nix</filename> "ties the knot" (creates the <filename>pkgs/top-level/stage.nix</filename> "ties the knot" (creates the
fixed point) of each stage. The package sets are defined per-stage however, fixed point) of each stage. The package sets are defined per-stage however,
so they can be thought of as edges between stages (the nodes) in a graph. so they can be thought of as edges between stages (the nodes) in a graph.
Compositions like <literal>pkgsBuildTarget.TargetPackages</literal> can be Compositions like <literal>pkgsBuildTarget.targetPackages</literal> can be
thought of as paths to this graph. thought of as paths to this graph.
</para> </para>
@ -581,12 +581,12 @@ nix-build &lt;nixpkgs&gt; --arg crossSystem '{ config = "&lt;arch&gt;-&lt;os&gt;
<varname>pkgsHostTarget</varname> refers to the current one, and <varname>pkgsHostTarget</varname> refers to the current one, and
<varname>pkgsTargetTarget</varname> refers to the next one. When there is <varname>pkgsTargetTarget</varname> refers to the next one. When there is
no previous or next stage, they instead refer to the current stage. Note no previous or next stage, they instead refer to the current stage. Note
how all the invariants about the mapping between dependency and depending how all the invariants regarding the mapping between dependency and depending
packages' build host and target platforms are preserved. packages' build host and target platforms are preserved.
<varname>pkgsBuildTarget</varname> and <varname>pkgsHostHost</varname> are <varname>pkgsBuildTarget</varname> and <varname>pkgsHostHost</varname> are
more complex in that the stage fitting the requirements isn't always a more complex in that the stage fitting the requirements isn't always a
fixed chain of "prevs" and "nexts" away (modulo the "saturating" fixed chain of "prevs" and "nexts" away (modulo the "saturating"
self-references at the ends). We just special case instead. All the primary self-references at the ends). We just special case each instead. All the primary
edges are implemented is in <filename>pkgs/stdenv/booter.nix</filename>, edges are implemented is in <filename>pkgs/stdenv/booter.nix</filename>,
and secondarily aliases in <filename>pkgs/top-level/stage.nix</filename>. and secondarily aliases in <filename>pkgs/top-level/stage.nix</filename>.
</para> </para>
@ -642,10 +642,10 @@ nix-build &lt;nixpkgs&gt; --arg crossSystem '{ config = "&lt;arch&gt;-&lt;os&gt;
</para> </para>
<para> <para>
Second, it is because this is a frequent source of hard-to-follow Second, it is because this is a frequent source of hard-to-follow
"infinite recursions" / cycles. When only packages sets that don't mention "infinite recursions" / cycles. When only package sets that don't mention
target are used, the package set forms a directly acyclic graph. This target are used, the package set forms a directed acyclic graph. This
means that all cycles that exist are confirmed to one stage. This means means that all cycles that exist are confined to one stage. This means
they are a lot smaller, so easier to follow in the code or a backtrace. It they are a lot smaller, and easier to follow in the code or a backtrace. It
also means they are present in native and cross builds alike, and so more also means they are present in native and cross builds alike, and so more
likely to be caught by CI and other users. likely to be caught by CI and other users.
</para> </para>
@ -653,7 +653,7 @@ nix-build &lt;nixpkgs&gt; --arg crossSystem '{ config = "&lt;arch&gt;-&lt;os&gt;
Thirdly, it is because everything target-mentioning only exists to Thirdly, it is because everything target-mentioning only exists to
accommodate compilers with lousy build systems that insist on the compiler accommodate compilers with lousy build systems that insist on the compiler
itself and standard library being built together. Of course that is bad itself and standard library being built together. Of course that is bad
because bigger derivation means longer rebuilds. It is also subpar because because bigger derivations means longer rebuilds. It is also problematic because
it tends to make the standard libraries less like other libraries than it tends to make the standard libraries less like other libraries than
they could be, complicating code and build systems alike. Because of the they could be, complicating code and build systems alike. Because of the
other problems, and because of these innate disadvantages, compilers ought other problems, and because of these innate disadvantages, compilers ought

2
doc/stdenv.xml
View File

@ -224,7 +224,7 @@ genericBuild
the dependency is needed at run-time or build-time, a concept that makes the dependency is needed at run-time or build-time, a concept that makes
perfect sense outside of cross compilation. By default, the perfect sense outside of cross compilation. By default, the
run-time/build-time distinction is just a hint for mental clarity, but with run-time/build-time distinction is just a hint for mental clarity, but with
<varname>strictDeps</varname> set it is somewhat enforced even in the native <varname>strictDeps</varname> set it is mostly enforced even in the native
case. case.
</para> </para>