Nixpkgs Stdenv | 230 Members | |
| 75 Servers |
| Sender | Message | Time |
|---|---|---|
| 28 Oct 2024 | ||
| https://hydra.nixos.org/build/274236521/nixlog/1 | 00:20:12 | |
| it's a Hydra problem. | 00:20:14 | |
| we could fix it in stdenv still, but it seems like the wrong place if actually the daemon stuff works | 00:20:55 | |
| so → #infra:nixos.org | 00:21:00 | |
| 31 Oct 2024 | ||
| 04:24:00 | ||
| 5 Nov 2024 | ||
| I was hoping replaceStdenv would act in a way to replace the stdenv; but not of buildPackages. What I see is that cmake appears to be built with my replacement stdenv, which is not quite what I expected. My next gambit was to use crossSystem but if I have localSystem == crossSystem, then buildPackages == pkgs and the cross machinery doesn’t kick in. My next gambit was to use stdenvStages but it looks like replaceStdenv is already implemented in exactly the way I was thinking to add a build stage. I would like a way to construct a package set with a custom compiler but to keep buildPackages as a standard set of packages. Is that doable somehow? | 14:18:45 | |
In reply to @p14:matrix.orgreplaceCrossStdenv | 14:22:42 | |
| 😄 | 14:22:52 | |
| I tried using replaceCrossStdenv but as I tried to say above, it does not take effect when localsystem is crosssystem | 14:23:30 | |
| So is there a way to use the cross system machinery when targeting local? | 14:23:41 | |
| Ha. I just needed to make the systems not equal. So adding crossSystem.custom = true seems to be enough to trigger it. Maybe this will work! The rebuilt set of packages looks promising. | 14:27:14 | |
| Annoyingly it looks like it is rebuilding gcc. | 14:27:41 | |
| Right, looks like because the compiler package name gets annotated with the cross triple, even though it is redundant in this case. | 14:28:59 | |
| Of course I can fix this up by making replaceCrossStdenv use the buildPackages compiler. Nice! Looks like I have what I want now… | 14:30:43 | |
| Found a case where it borks, firefox refuses to eval with unsupported platforms in wasilibc, because it has meta platforms = wasm*. Odd. The non-cross version is fine as expected. | 14:38:00 | |
| 6 Nov 2024 | ||
| is there any documentation (of really any kind) in regards to the inner working on how stdenv works? I find it a little bit difficult to follow the many multiple levels of nix code in nixpkgs, and was wondering if any kind of documentation exists, such as how the process works especially for cross environments | 23:03:17 | |
In reply to @frontear:matrix.orgThe cross part is easy because you do not have to deal with bootstrapping | 23:04:09 | |
| Here's some crumbs I sent to someone before
(edited the lib files out) https://github.com/NixOS/nixpkgs/blob/0d2ff894cb4d1bcb1b5006aa68c8cc87051b7741/pkgs/top-level/stage.nix#L308-L316 | 23:05:53 | |
Literally SomeoneSerge (utc+3) | 23:06:43 | |
| haha | 23:06:48 | |
| appreciated looks like need to write down some notes as i read these thank you | 23:10:18 | |
| https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/linux/default.nix | 23:11:19 | |
| vs cross https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/cross/default.nix | 23:11:31 | |
| 699 lines vs 107 | 23:11:41 | |
| honestly i expected the complete opposite | 23:12:00 | |
| id expected cross setup to be more difficult | 23:12:11 | |
| The hard work of bootstrapping is done in the native stages | 23:12:37 | |
| So cross is mostly just compiling packages like normal | 23:13:28 | |
| 7 Nov 2024 | ||
Yeah. It still needs to build cross-gcc twice (and arguably does it slightly incorrectly WRT libgcc.so), but it's not as involved as native tools are already there (and use native bootstrap). | 16:56:46 | |
| 8 Nov 2024 | ||
| 14:29:49 | ||