Make cross compilation elegant#26805
Conversation
2fa41a1 to
8de191a
Compare
There was a problem hiding this comment.
Shouldn't this be PREFIX=${hostPlatform.config}-? (Or at least not stdenv.cross ...?)
There was a problem hiding this comment.
Inverted logic? Isn't it so that when you're building for host != build, then you'd like to use "install" from the buildPackages set?
pkgs/stdenv/generic/setup.sh
Outdated
There was a problem hiding this comment.
Should one of these "m"s be "n"?
There was a problem hiding this comment.
hehe, too much copy paste
|
The commit message in "stdenv: Fix handling of dependencies and hooks" says
I think it'd be nice if the documentation in the commit message was added to "pkgs/stdenv/generic/setup.sh". |
|
I have nothing to say about the code other than the nitpicks above. Looks good to me! I'm always happy to see you work on cross-compilation :-) |
There was a problem hiding this comment.
This should have been configurePlatforms, but that wasn't shows that isn't needed after all!
eba946a to
e388be3
Compare
There was a problem hiding this comment.
Actually it is. I changed makefile to only define the c compiler as a fallback: CC ?= cc. What I can do is give the patch a better name :)
There was a problem hiding this comment.
What I meant the trailing semicolon might be unintended, isn't it?
e388be3 to
f6a1d58
Compare
|
OK renamed patches and overhauled documentation. |
ba655a4 to
b80754c
Compare
|
Cleaned up cc-wrapper, and made misc packages use The stdenv commit unfortunately causes some infinite reversion. No idea why; if anyone could figure out that would be much appreciated. |
|
It really makes it pretty hard to review or follow things like this when every change on this topic is a batch of commits with a total of several hundred lines of changes, often later getting closed with "I redid all this work in PR 12345". Like you saying, "hey the third commit of six has an obscure bug I haven't been able to figure out; please help!" might be a hint that you're lumping too much together. Especially when that problematic commit then has a commit message starting with "3 big changes: ". It's just daunting to me, and I doubt I'm alone. Don't get me wrong: I appreciate all the work you're putting in here, and appreciate descriptive commit messages, but I think this tweet sums up my position on code reviews. Too small and they tend to be nitpicky, but too big and there's just too much going on for anyone to get enough context to provide a meaningful review without investing an hour or more into it, which is more than most people are willing to put in. If your goal as a code author is to get meaningful feedback from other people with relevant expertise, I'd urge you to not only optimize your code for correctness (which you're probably fine with) but optimize your coding practice to enable the rest of us to see that it's correct. That'll mean smaller, more focused commits, more focused PRs, even if that sometimes means not writing a feature the way it comes naturally to you, in order to make it more incremental and consumable by the rest of us. Anyway, that's just my two cents. Please don't take it as anything more than what I'm saying. I really want your stuff to land and generally love and appreciate all the cross-compilation revamp and cleanup work you've been doing, but I fairly consistently can make very little sense of your PRs. That might just be me, of course 😄 |
|
Okay, I take some of that back, sorry. After looking more carefully at the stdenv commit in question, I now see that most of the changes are documentation changes, which I really appreciate, and the remainder is fairly small logic. I just knee-jerked too hard at the "3 big changes" in the commit message. Anyway, given that, I don't know if there's much remaining truth to my original point but I'll leave it up and see what you think. |
This commits needs a MAJOR audit as I oftentimes just guessed which of `$hostOffset`, `$targetOffset`, or a fixed offset should be used.
libgcc.a and similar
- All deps go on the PATH - CC and Bintools wrappers with their host != depender's host still get their setup hooks run. - Environment hooks get applied to all packages This isn't so elegent, but eases the transition on a very significant PR.
It was improperly classified a build-time dep to get around the incorrect propagation logic that was in place before this PR. Additionally fix some `kdoctools` usage were it is incorrectly used a run-time dep.
280af3a to
626136a
Compare
|
@bgamari Thanks for your very thoughtful and thorough review! I fixed everything I could (including start cookbook with your examples) that wouldn't cause a mass rebuild (e.g. more comments in I'll be around a lil bit tomorrow to help put out any fires (e.g. some rustc on Darwin) that may arise. Code-churn wise, this cross saga is all downhill from hill. :) |
This accounts for all the new dependencies and propagation logic changes I'm about to add. Fixes NixOS#1915---with this change I think the distinction is finally clear enough.
626136a to
bfe3b82
Compare
bfe3b82 to
a98e686
Compare
|
Wow this is merged now! Congrats! |
|
|
||
| # Ensure we're in bounds relative to the package currently | ||
| # being built. | ||
| [[ "${allPlatOffsets[*]}" = *"$hostOffsetNext"* ]] || continue |
There was a problem hiding this comment.
This naïve substring match considers 1 to be a substring of -1. Did you mean to write this?
- [[ "${allPlatOffsets[*]}" = *"$hostOffsetNext"* ]] || continue
+ [[ " ${allPlatOffsets[*]} " = *" $hostOffsetNext "* ]] || continue
Motivation for this change
#26881 has the easy cleanups of individual derivations, but there is some more complex cleanups to core infrastructure that should also be made. This PR is for them.
Because these changes are both complex, and cause huge mass rebuilds, it will take longer to get right. I might or might not might land #26799 or #25047 in the meantime, for example. Opening now because such changes warrant much discussion.
When #26881 is merged, I'll repoint those hydra jobs at this.
Things done
@periklis I opened https://github.com/NixOS/nixpkgs/projects/8 as a meta-issue; also see these new TODOs below.
besidesincluding MinGW) http://hydra.nixos.org/jobset/nixpkgs/ericson2314-cross-trunk(propagated)buildInputsback on thePATHwhen not cross-compiling, to lessen potential breakage.---but I want to make sure at least the stdenv builds before I do this.Don't prune native of native, to lessen potential breakage.Breakage dealt with despite this__(some in docs, it seems)CC @Dridus @matthewbauer @DavidEGrayson @bgamari