Conversation
d4fb336 to
905f288
Compare
Ericson2314
left a comment
There was a problem hiding this comment.
Yeah agreed this seems strictly better.
|
FWIW this works fine with a package that I maintain that depends on |
905f288 to
3a38b49
Compare
|
took a while to build, but |
3a38b49 to
3df2182
Compare
|
@Ericson2314 can I get your ack for dropping the assertion that at most one of "rust" and "rustc" is given? Caused eval to fail; reason now explained in the first commit message. |
lib/systems/default.nix
Outdated
There was a problem hiding this comment.
| }; | |
| } // (args.rust or {}); |
Otherwise people have no way to override any of this stuff without editing this file.
Previously // args was the last thing in the //-chain, which provided an escape hatch.
There was a problem hiding this comment.
I don't think that works. If you pass { rust.platform = { arch = …; os = …; }; }, target-family is supposed to be filled in automatically. If we did a merge like this at the end, the whole platform attrset would be overridden with just the values you passed, so target-family wouldn't end up being there.
There was a problem hiding this comment.
I'm also not confident that this needs to be supported, at least not right now. It was never supported when these were in rust.lib, except by using an overlay, which you could also use in this situation. It would be a bit ugly, but making workarounds for things be ugly when they're fixable bugs in the underlying code is not the worst thing, because it encourages fixing the thing rather than working around it.
|
@ofborg eval |
3df2182 to
6846d96
Compare
Usually, attributes passed explicitly to elaborate take precedence
over the elaborated ones, but since we also elaborate the nested
"rust" attrset, we need to push that one level down, so the rest of
"rust" is still filled in if you just pass
{ rust = { config = ... } }.
I've had to drop the assertion that checked that at most one of "rust"
and "rustc" was part of the un-elaborated system, because doing this
broke passing an elaborated system in, which should be idempotent.
For the same reason, I've also had to make it possible for
rust.rustcTargetSpec to be passed in. Otherwise, on the second call,
since platform was filled in by the first, the custom target file
would be constructed. The only other way to avoid this would be to
compare the platform attrs to all built in Rust targets to check it
wasn't one of those, and that isn't feasible.
Fixes: e3e57b8 ("lib.systems: elaborate Rust metadata")
The previous version stopped working when we started elaborating Rust metadata. Here, I've made it a bit nicer by actually setting targetPlatform to an elaborated system. Setting the config to wasi to get elaborate to understand it is a bit of a hack, but I think it's less of a hack than what we had before. The only actual difference this makes to the rustc-wasm32 derivation compared to the previous working version, is that now crt-static is set. This is probably the right thing anyway. Fixes: e3e57b8 ("lib.systems: elaborate Rust metadata")
6846d96 to
886c892
Compare
Also had to make it possible to pass in |
|
Pardon the question, but what is left to get this merged? |
|
I would still like @Ericson2314's ack for the changes I mentioned. |
bendlas
left a comment
There was a problem hiding this comment.
I'm currently running this patchset to fix lldap for my deployments.
|
IMO we should merge this as-is. It's strictly better than the current situation, since there are broken packages depending on this fix, and if @Ericson2314 has any concerns they can be addressed in a follow-up PR. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Successfully created backport PR for |
|
This change broke rustc on armv7l-linux and riscv64-linux when evaluating with NixOS system: Used commands: git bisect start
git bisect good 19cbff5
git bisect bad e92039b55bcd
git bisect run nix-build nixos -A pkgs.rustc --argstr system riscv64-linux -I nixos-config=test.nix --dry-run
{
boot.loader.grub.device = "/dev/sda";
fileSystems."/".device = "/dev/sda1";
services.sshd.enable = true;
}See #271000 for more info |
Description of changes
See commit messages. Fixes a couple of regressions from #233628.
wasm32-rustc is still not ideal. As followup, I'd like to investigate whether we could just always include the wasm32-unknown-unknown target in rustc builds, since it doesn't require any libc dependency or anything.
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)