summary refs log tree commit diff
path: root/doc/stdenv
diff options
context:
space:
mode:
authorRobert Hensing <roberth@users.noreply.github.com>2020-12-15 11:45:38 +0100
committerGitHub <noreply@github.com>2020-12-15 11:45:38 +0100
commitc7e5c023744adce6e651cf20580cc0c59fb6f158 (patch)
tree6a62567d35482f3c1e4844a21448adbf52f2837b /doc/stdenv
parent12f367b51cafa511161b1af76f9ccc47c2dde6cb (diff)
downloadnixpkgs-c7e5c023744adce6e651cf20580cc0c59fb6f158.tar
nixpkgs-c7e5c023744adce6e651cf20580cc0c59fb6f158.tar.gz
nixpkgs-c7e5c023744adce6e651cf20580cc0c59fb6f158.tar.bz2
nixpkgs-c7e5c023744adce6e651cf20580cc0c59fb6f158.tar.lz
nixpkgs-c7e5c023744adce6e651cf20580cc0c59fb6f158.tar.xz
nixpkgs-c7e5c023744adce6e651cf20580cc0c59fb6f158.tar.zst
nixpkgs-c7e5c023744adce6e651cf20580cc0c59fb6f158.zip
doc/cross-compilation: Remove confusing re-explanation
See https://github.com/NixOS/nixpkgs/issues/106950

> They way it's worded says buildInputs are for build-time and nativeBuildInputs are for run-time. The other documentation leads me to believe it is the other way around.
Diffstat (limited to 'doc/stdenv')
-rw-r--r--doc/stdenv/cross-compilation.chapter.md2
1 files changed, 1 insertions, 1 deletions
diff --git a/doc/stdenv/cross-compilation.chapter.md b/doc/stdenv/cross-compilation.chapter.md
index bc7a1a13817..bdade81466e 100644
--- a/doc/stdenv/cross-compilation.chapter.md
+++ b/doc/stdenv/cross-compilation.chapter.md
@@ -75,7 +75,7 @@ A run time dependency between two packages requires that their host platforms ma
 
 A build time dependency, however, has a shift in platforms between the depending package and the depended-on package. "build time dependency" means that to build the depending package we need to be able to run the depended-on's package. The depending package's build platform is therefore equal to the depended-on package's host platform.
 
-If both the dependency and depending packages aren't compilers or other machine-code-producing tools, we're done. And indeed `buildInputs` and `nativeBuildInputs` have covered these simpler build-time and run-time (respectively) changes for many years. But if the dependency does produce machine code, we might 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 platforms, but we prohibit dependencies from a "later" platform to an earlier platform to limit confusion because we've never seen a legitimate use for them.
+If both the dependency and depending packages aren't compilers or other machine-code-producing tools, we're done. And indeed `buildInputs` and `nativeBuildInputs` have covered these simpler changes for many years. But if the dependency does produce machine code, we might 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 platforms, but we prohibit dependencies from a "later" platform to an earlier platform to limit confusion because we've never seen a legitimate use for them.
 
 Finally, if the depending package is a compiler or other machine-code-producing tool, it might need dependencies that run at "emit time". This is for compilers that (regrettably) insist on being built together with their source languages' standard libraries. Assuming build != 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 emitted by the compiler.