Cross lib foundation #25099
Cross lib foundation #25099
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
| @@ -167,6 +167,11 @@ | |||
| Because of this, a best-of-both-worlds solution is in the works with no splicing or explicit access of <varname>buildPackages</varname> needed. | |||
| For now, feel free to use either method. | |||
| </para> | |||
| <note><para> | |||
| There is also a "backlink" <varname>__targetPackages</varname>, yielding a package set which whose <varname>buildPackages</varname> is the current package set. | |||
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
| in | ||
| f_0 | ||
|
|
||
| New in 17.10 --- Until that release is cut, feel free to modify this |
There was a problem hiding this comment.
Nitpick: I think it's 17.09 not 17.10
pkgs/top-level/stage.nix
Outdated
| # defined internally as the produced package set as itself. | ||
| # | ||
| # THIS IS A HACK for compilers that don't think critically about cross- | ||
| # compilation. Please do *not* use unless you really know what you are doing. |
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
| New in 17.10 --- Until that release is cut, feel free to modify this | ||
| function (and update its uses accordingly). | ||
| */ | ||
| dfold = op: lnul: rnul: list: |
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.
| @@ -87,6 +94,8 @@ let | |||
| stdenvBootstappingAndPlatforms = self: super: { | |||
| buildPackages = (if buildPackages == null then self else buildPackages) | |||
| // { recurseForDerivations = false; }; | |||
| __targetPackages = (if __targetPackages == null then self else __targetPackages) | |||
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
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/)