| 11 May 2025 |
 p14 | But is there a good reason to put the unwrapped CC in the path? I have dropped it without ill effect and it does fix things ion my case. | 17:17:03 |
 emily | we don't but we do want prefixed compilers | 17:18:55 |
| emily | so the prefixed ones should probably be wrapped | 17:19:10 |
| p14 | So, could https://github.com/NixOS/nixpkgs/blob/1a5bd697adecf27385b69352485baa52a6e02fe9/pkgs/build-support/cc-wrapper/setup-hook.sh#L92-L94 and https://github.com/NixOS/nixpkgs/blob/1a5bd697adecf27385b69352485baa52a6e02fe9/pkgs/build-support/bintools-wrapper/setup-hook.sh#L39-L41 be dropped.
In light of the commit message here https://github.com/NixOS/nixpkgs/pull/182385/commits/e682dd84cff5d2420fcc0a40508557477f6cc9d3 which comments that it was unknown why there were in the path (but the answer is linked above). Now it is found, can we delete it? :) | 18:42:09 |
| p14 | I'm thinking that essentially if there is some binary provided by the compiler and it's not symlinked into the wrapper, that is a bug. | 18:43:42 |
| p14 | While messing with the booting machinery I am hitting an odd thing where somehow a meson is creeping in which has an openmp dependency which creates an infinite cycle. Haven't debugged it yet. (clang -> tblgen -> cmake -> libarchive -> e2fsprogs -> fuse -> meson (from some other stage) -> openmp -> infinite cycle on clang). I guess I need to plug something into my stdenv overrides to prevent this. | 18:54:42 |
 @trofi:matrix.org | e2fsprogs -> fuse can be broken by disabling withFuse = false; | 18:56:41 |
| p14 | Do you happen to know of any good ways to visualise the dependency graph across the stages? I've resorted to injecting names into derivations to indicate which stage they're in, which helps, but within a stage it can be helpful to understand the why-depends relationships of things without having to manually invoke it repeatedly. | 19:03:57 |
 Randy Eckenrode | https://github.com/NixOS/nixpkgs/blob/5d0f68d3c0af3ecd33697bccfba40f73c82526ca/pkgs/stdenv/linux/default.nix#L33-L55 | 19:12:34 |
| Randy Eckenrode | Should work for any stdenv that follows similar stage naming conventions. | 19:12:52 |
| Randy Eckenrode | (I’ve used it when working on Darwin’s.) | 19:13:00 |
| @trofi:matrix.org | +1. Yeah, I usually use that with a bit of grep tweaks. | 19:25:18 |
| p14 | It'd be great if the stdenvs had differing names (I have given mine different names, but I'm also thinking of those appearing by use of overrideCC within llvm common. | 20:28:59 |
| Randy Eckenrode | Darwin’s stdenv is stdenv-darwin, and its bootstrap stages are suffixed with -stdenv-darwin, but they follow the same bootstrap-stageX convention that Linux does, so that grep works on Darwin. | 20:46:32 |
| Randy Eckenrode | * Darwin’s stdenv is stdenv-darwin, and its bootstrap stages are suffixed with -stdenv-darwin, but they follow the same bootstrap-stageX convention that Linux does, so that grep still works. | 20:46:42 |
| 16 May 2025 |
 Tristan Ross | NixOS 25.05 has branched off, if we're ready to bump LLVM then we can undraft https://github.com/NixOS/nixpkgs/pull/407738.
CC Randy Eckenrode emily
| 21:56:46 |
