top-level: Create pkgs{Build,Host,Target}{Build,Host,Target}
#57611
Conversation
Ericson2314
added
the
6.topic: cross-compilation
GrahamcOfBorg
added
6.topic: golang
6.topic: haskell
6.topic: stdenv
pkgs/top-level/stage.nix
Outdated
|
|
||
| # Older names for package sets. Use these when only the host platform of the | ||
| # package set matter (i.e. use `buildPackages` where any of `pkgsBuild*` | ||
| # would do, and `targetPackages` when any of `pkgsTarget*` would do.) |
There was a problem hiding this comment.
There’s only one pkgsTarget* right?
There was a problem hiding this comment.
Yes. I should make that clear I'm saying would there be more than one it wouldn't matter.
| # pkgsTargetTarget ...; | ||
| # } | ||
| # | ||
| # These are references to adjacent bootstrapping stages. The more familiar |
There was a problem hiding this comment.
Maybe put this in Nixpkgs documentation.
| else assert targetPlatform == hostPlatform; # build != host == target | ||
| [ stdenv.cc ] ++ stdenv.lib.optional useLLVM buildLlvmPackages.llvm; | ||
| toolsForTarget = [ | ||
| pkgsBuildTarget.targetPackages.stdenv.cc |
There was a problem hiding this comment.
Why do you need targetPackages here?
There was a problem hiding this comment.
because stdenv.cc comes from the previous stage. targetPackages.stdenvsort of cancels out so I get something likepkgsBuildTarget.gccorpkgsBuildTarget.llvm` in the end.
| @@ -22,7 +22,7 @@ | |||
|
|
|||
| depsBuildBuild = [ buildPackages.stdenv.cc ] | |||
There was a problem hiding this comment.
Should pkgsBuildBuild be used here?
There was a problem hiding this comment.
It would have to be pkgsBuildBuild.targetPackages.stdenv.cc, so ehh hardly worth it for now.
| # platform. We only care about their host/target platforms, not their build | ||
| # platform, because the the former two alone affect the interface of the | ||
| # final package; the build platform is just an implementation detail that | ||
| # should not leak. |
There was a problem hiding this comment.
Please put also this into the documentation.
Ericson2314
force-pushed
the
stage-braid-not-chain
branch
from
a702c03 to
3cd8bff
Compare
GrahamcOfBorg
added
the
8.has: documentation
|
CC @shlevy here is that change the reduces the importance of the sliding window. |
| if args.stdenv.hostPlatform == args.stdenv.targetPlatform | ||
| then thisStage | ||
| else assert args.stdenv.buildPlatform == args.stdenv.hostPlatform; pkgsBuildHost; | ||
| pkgsTargetTarget = nextStage; |
There was a problem hiding this comment.
Here is the proof while stages are "braided" not "chained" (more edges between them than buildPackages targetPackages), there are no more stages than before (same nodes).
There was a problem hiding this comment.
But if we ever had any stages that were canadian cross (build != host != target) then we would need more stages, as no {linear, sliding window}-generated stage would fit pkgsBuildTarget or pkgsHostHost. This relates to those two being conditionally hacked together above from the linear ones, while the rest are statically chosen.
Ericson2314
force-pushed
the
stage-braid-not-chain
branch
2 times, most recently
from
b494854 to
5aed659
Compare
$(shell ...) looks a little sketch like it will be run no matter what. And there are problems building the manual on darwin so hopefully this fixes them.
This is needed to avoid confusing and repeated boilerplate for `fooForTarget`. The vast majority of use-cases can still use `buildPackages or `targetPackages`, which are now defined in terms of these.
`pkgsBuildTarget` allows us to avoid repeated and confusing conditions. The others merely provide clarity for one the foreign package set's target platform matters.
There was a bunch of stuff in the cross section that haddn't had any attention in a while. I might need to slim it down later, but this is good for now.
Ericson2314
force-pushed
the
stage-braid-not-chain
branch
from
5aed659 to
5e5266f
Compare
| that packages should be written with cross-compilation in mind, and nixpkgs | ||
| should evaluate in a similar way (by minimizing cross-compilation-specific | ||
| special cases) whether or not one is cross-compiling. | ||
| run-time environments! Significant, because the benefits apply even when one |
There was a problem hiding this comment.
| run-time environments! Significant, because the benefits apply even when one | |
| run-time environments! |
| should evaluate in a similar way (by minimizing cross-compilation-specific | ||
| special cases) whether or not one is cross-compiling. | ||
| run-time environments! Significant, because the benefits apply even when one | ||
| is developing and deploying on the same machine. Nixpkgs is increasingly |
There was a problem hiding this comment.
| is developing and deploying on the same machine. Nixpkgs is increasingly | |
| Nixpkgs is increasingly |
| review changes from pull request number 12345: | ||
| <screen>nix-shell -p nix-review --run "nix-review pr 12345"</screen> | ||
| review changes from pull request number 12345: | ||
| <screen>nix-shell -p nix-review --run "nix-review pr 12345"</screen> |
There was a problem hiding this comment.
That is the autoformatter.
| likely to be caught by CI and other users. | ||
| </para> | ||
| <para> | ||
| Thirdly, it is because everything target-mentioning only exists to |
There was a problem hiding this comment.
I disagree. A compiler will never be able to build everything, so the you will always need to keep track of target. Things like LLVM get close to compiling everything, but we might prefer to only build the part of LLVM we need.
There was a problem hiding this comment.
That's a good point. I think part of the answer is targetPlatform is less bad than targetPackages. I'll merge this now to unblock other stuff, but get back to fixing that wording later.
Thanks @matthewbauer! Co-Authored-By: Ericson2314 <git@JohnEricson.me>
Motivation for this change
top-level: Create
pkgs{Build,Host,Target}{Build,Host,Target}This is needed to avoid confusing and repeated boilerplate for
fooForTarget. The vast majority of use-cases can still usebuildPackages ortargetPackages`, which are now defined in terms ofthese.
ghc, go, guile: Use new
pkgs*pkgsBuildTargetallows us to avoid repeated and confusing conditions.The others merely provide clarity for one the foreign package set's
target platform matters.
Things done
sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)nix path-info -Sbefore and after)