-
-
Notifications
You must be signed in to change notification settings - Fork 14.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
aarch64: enable rebootstrap, upgrade to gcc11 #209462
Conversation
@ofborg build protobuf The |
I'm not a fan of this "rebootstrap" principle. Maybe I'm confused. You considered adding one gcc rebuild too heavy, but this seems to add a rebuild of all bootstrap tools (including much more than gcc). Yes, it could be selected by platform, but from my point of view that adds even more complexity. Rather than this, I'd consider relatively simple update of bootstrap tools for aarch64-linux.
|
Only on aarch64.
Not really; most of it is stuff that gcc already depends on. Especially if you measure by build time (which is what matters) rather than package count. Basically it's just
No, you are misrepresenting my position there. Both this PR and #209063 are temporary fixes; either way they get reverted down the line when we implement the proper fix by making The difference is that this PR is a two-line change, trivial to revert. Its parent PR, #209459, is independently useful, and in any event doesn't muck around with the internals of the stdenv stages. No technical debt.
That works too. |
@ofborg build protobuf |
If we look at Before:
After:
[UPDATE: included single-time builds to make lists more comparable in length to avoid false impression] |
Do you really think it's reasonable to count how many times a downloaded patch is used as a build input? |
I don't think it is, but I did not intend to remove them. I removed filters completely and updated the comment. |
The extra gcc build is because glibc can't do static linking. So the bootstrap busybox is built with musl, which gets its own build of gcc. It's easy to avoid by copying the statically-linked |
Heh, that will make it Presence of It also might actually make pulling in patches as derivations slightly more significant: |
No, everything upstream of
The long-term fix is #188587, but it needs nix features that are experimental (and also not very well-tested yet). |
I would like to emphasize that the point of this PR is avoiding technical debt in Latest push has the same number of The script at the end of this comment is useful for comparisons. Whatever arguments you pass to it, it will pass on to For example, to see the rebuilds that this PR avoids on every platform except aarch64:
|
@ofborg build icu protobuf |
On my 8 core aarch64-linux VM running 2 jobs in parallel, building the entire stdenv from scratch with no substitutions takes over 150% longer wallclock time with the latest edition of this PR ( If I understand correctly as well, any change whatsoever to the stdenv will require the full time to build a stdenv (40 minutes above) plus whatever partial bootstrap rebuild is possible. The bootstrap tools have more programs than the stdenv AFAIK, so there are also more changes which will result in stdenv rebuilds. I would much rather upgrade the bootstrap tools than use this (except possibly in the upgrading of the bootstrap tools). I did verify though this successfully builds the two test packages (
|
You need to use #209601 for build-time experiments. |
I fixed a few bugs in the compare.sh script. Here are the build diffs of #209063 vs #209601 (this PR plus rebuild optimizations). Personally I think focusing on added aarch64 rebuilds, while ignoring added rebuilds on all other platforms is just kooky. That's why I kept the rebuild optimizations separate from this PR. Lines starting with a Bottom line is that it's the same number of Frankly I think the fixation on rebuilds (and only aarch64 rebuilds, ignoring all other platforms) is pretty silly. But I will play along.
|
Description of changes
I would like to emphasize that the point of this PR is avoiding technical debt in
stdenv
. The fact that it saves rebuilds in some situations is just an added bonus.This PR is a two-line change, trivial to revert. Its parent PR, #209459, is independently useful, and in any event doesn't muck around with the internals of the stdenv stages.
This PR has a child, #209601, which greatly reduces the amount of aarch64 rebuilds, at the expense of complexity. I'm not sure the complexity is worth it; the point of that PR is to show that there are various complexity/performance tradeoff points available to choose from.
Motivation:
Incorporates changes from:
Should fix:
Alternative to:
Things done