Conversation
Ericson2314
added
the
6.topic: cross-compilation
|
@Ericson2314, thanks for your PR! By analyzing the history of the files in this pull request, we identified @edolstra, @zimbatm and @Profpatsch to be potential reviewers. |
doc/cross-compilation.xml
Outdated
There was a problem hiding this comment.
"which whose" is a little awkward... I'm not sure what to use but I think just using one of those words is enough.
There was a problem hiding this comment.
Yeah should just be "whose".
lib/lists.nix
Outdated
There was a problem hiding this comment.
Nitpick: I think it's 17.09 not 17.10
pkgs/top-level/stage.nix
Outdated
There was a problem hiding this comment.
Just curious, but what compilers need __targetPackages? It looks like from your other commits that it is only used by glibc?
There was a problem hiding this comment.
GHC, certain GCC stages as exists, cc-wrapper with libc.
lib/lists.nix
Outdated
There was a problem hiding this comment.
I’m really not sure this is general enough to be in the base library. The use-cases seem very limited.
There was a problem hiding this comment.
Moved out of lib and into booter.nix for now.
pkgs/top-level/stage.nix
Outdated
There was a problem hiding this comment.
Using null here seems kind of forced—what’s the difference to []?
There was a problem hiding this comment.
Err it would normally be an attribute set. I wanted to distinguish { .. } --- the target package set is different and contains these packages , from null -- the target package set is the same as the regular package set. This allows me to avoid splicing, which is expensive.
There was a problem hiding this comment.
https://github.com/NixOS/nixpkgs/pull/25099/files#diff-69df24a05ec3d577cb638113e9837ae1R52 is a somewhat poorly-worded explanation of that.
Ericson2314
force-pushed
the
cross-lib-foundation
branch
3 times, most recently
from
12f02e7 to
fad54d8
Compare
- `pkgs` is self-similar, and thus already spliced - `buildPackages` is an ingredient of splicing and should be kept as is - The platforms are not packages or package sets and couldn't be spliced There's probably other things that shouldn't be spliced too. The best long- term solution is simply to stop splicing altogether.
Each bootstrapping stage ought to just depend on the previous stage, but poorly-written compilers break this elegence. This provides an easy-enough way to depend on the next stage: targetPackages. PLEASE DO NOT USE IT UNLESS YOU MUST! I'm hoping someday in a pleasant future I can revert this commit :)
Ericson2314
force-pushed
the
cross-lib-foundation
branch
from
fad54d8 to
863d79b
Compare
Ericson2314
dismissed
Profpatsch’s stale review
Moved dfold out of lib and clarified answer to question in code
4 participants
Motivation for this change
Two innocent native- and cross-hash-preserving change from #25047. It's hard to motivate them on their own (and this is the second sub PR I've made!) but trust me they're needed :). At least they are safe to merge on their own.
[Oh, alright, the first fixes some bugs were we splice together the splice leading packages to bleed past adjacent stages (only adjacent stages are spliced). The second allows compile package hacks where we need to break the rules and depend on something from a future stage because the compiler insists on building the standard library.]
Things done
(nix.useSandbox on NixOS,
or option
build-use-sandboxinnix.confon non-NixOS)
nix-shell -p nox --run "nox-review wip"./result/bin/)