Sender | Message | Time |
---|---|---|
1 Jul 2025 | ||
In reply to @niklaskorz:matrix.orgRust update perhaps? If it's something unintended it could perhaps be discovered, reported and fixed. Is it bisectable? | 08:04:59 | |
I hoped to avoid bisecting because of the large build times, but maybe I can speed it up a bit by disabling the check phase 😄 (both buildPhase and checkPhase had an equal increase in build time, so that should suffice) | 08:06:57 | |
will do and report back | 08:07:01 | |
Well, if you have a Rust update in range, you could speculate that it's that and test that first rather than doing a whole Nixpkgs bisect | 08:09:23 | |
When I bisect I'm also scanning the commits in range to find likely causes, not always following the midpoint it gives me to test. | 08:09:59 | |
right, thanks! I’ll start with the Rust 1.86 -> 1.87 commit then | 08:11:22 | |
Idea smoke test: Problem: You probably don't understand what on earth the difference between
These are only different if you specify
As it stands today ~nobody gets it right. Nixpkgs docs lies about the file name of Idea: Proposal: Phase 1:
Phase 2:
See: https://github.com/NixOS/nixpkgs/pull/420797#pullrequestreview-2969405491 | 14:04:02 | |
We deliberately moved these out of rustPlatform and into lib.systems | 14:20:59 | |
And I broadly disagree that almost nobody gets it right | 14:23:27 | |
how about something that takes a pkgs , like emulator ? | 14:31:21 | |
That's a very bad pattern that completely defeats the purpose of lib. Absolutely not a precedent to build on | 14:32:08 | |
then we would need to make either users adapt if they want to support rust.platform , or some way to generate a directory without pkgs | 14:34:00 | |
Layering violation | 14:36:37 | |
The rust-hypervisor-firmware package is also doing something deeply wrong (reimporting Nixpkgs) and as a result hasn't worked for the majority of time it's been in Nixpkgs. It's not a good example of what we'd like to accommodate. The only reason it was done that way was that at the time our normal Rust compiler couldn't build for embedded targets due to an upstream bug that has since been fixed. | 14:36:38 | |
okay let's put aside rust-hypervisor-firmware for now, and focus on why i want to merge rustcTarget and cargoShortTarget | 14:41:29 | |
you say that you disagree that almost nobody gets it right? | 14:41:48 | |
maybe i was being hyperbolic but from what i read it seems random on which one users end up going for | 14:42:36 | |
In reply to @niklaskorz:matrix.orgfyi I can't reproduce the long build durations anymore now and I didn't know hydra build durations vary a lot in general, I'll just blame the current heat wave and thermal throttling 🫠 | 14:43:05 | |
Then let's fix the packages using the wrong one that people might copy and paste from, and improve the documentation to lead people to the right one. | 14:43:17 | |
for example, target/${stdenv.hostPlatform.rust.rustcTargetSpec}/ vs target/${stdenv.hostPlatform.rust.cargoShortTarget}/ | 14:43:18 | |
* for example, target/${stdenv.hostPlatform.rust.rustcTarget}/ vs target/${stdenv.hostPlatform.rust.cargoShortTarget}/ | 14:43:27 | |
Well that one actually is already clearly documented | 14:43:37 | |
or even target/${stdenv.hostPlatform.rust.rustcTargetSpec}/ | 14:43:40 | |
So not sure we can do too much about that. I don't think we can merge them because they're fundamentally different things. | 14:43:55 | |
wait, i don't understand what rustcTarget is then | 14:46:40 | |
Away from computer for a moment but it's very rare for rustcTarget to be the right thing. | 14:53:49 | |
I think "--set=target.${stdenv.hostPlatform.rust.rustcTarget}" would be a correct use of rustcTarget | 15:12:43 | |
in rustc.nix | 15:12:51 | |
But I'm getting more confused the more I look at it | 15:14:33 | |
I would like to understand what the process of configuring the rustc build for a custom target looks like | 15:16:20 |