| 3 Nov 2025 |
 winston | I see that's currently being patched out for x86_64 https://github.com/NixOS/nixpkgs/blob/56dec699a244539d32a00a11c6c18a27a9c5c4a7/pkgs/development/compilers/llvm/common/llvm/default.nix#L299-L337 | 18:09:15 |
| winston | think this does the trick https://github.com/NixOS/nixpkgs/pull/458211 | 19:24:41 |
 Grimmauld (any/all) | needs to go to staging-next, right? doxygen is already broken there for aarch64 darwin | 21:29:06 |
| winston | ah, will switch the targeting branch then | 21:30:32 |
| Grimmauld (any/all) | i also suspect this might be yet again killing builds we already have on linux... This cycle is getting increasingly scuffed, and we are in freeze month... | 21:32:15 |
| Grimmauld (any/all) | we should eventually also switch doxygen to build against qt6 instead, but that change can come later and against staging (not next) | 21:34:43 |
| winston | should i just get rid of everything but the optionalString darwin | 21:35:12 |
| Grimmauld (any/all) | i suspect there may be cyclic dependency avoidances that are required to pull that of | 21:35:23 |
| Grimmauld (any/all) | if you make it zero-rebuild on linux, then yes i'd see no issue merging.
If you do have rebuilds on linux, i want an okay from vcunat or k900 | 21:35:58 |
| winston | zero-rebuild on linux now according to labels | 21:45:35 |
| Grimmauld (any/all) | According to https://cmake.org/cmake/help/latest/prop_tgt/INTERPROCEDURAL_OPTIMIZATION.html#prop_tgt:INTERPROCEDURAL_OPTIMIZATION, the option is specific to compilers. Does the same issue happen on pkgsLLVM.doxygen? | 21:46:44 |
| winston | i'll run a build | 21:47:06 |
| Grimmauld (any/all) | I am wondering whether we want stdenv.hostPlatform.isDarwin or rather stdenv.hostPlatform.isClang | 21:47:08 |
| Grimmauld (any/all) | * I am wondering whether we want stdenv.hostPlatform.isDarwin or rather stdenv.cc.isClang | 21:47:19 |
| winston | yep makes sense | 21:47:58 |
| Grimmauld (any/all) | if you don't have a build already, i'll throw it on the aarch64-linux community builder, that is the fastest we have | 21:50:18 |
| winston | mh how do I do that? | 21:50:42 |
| winston | pretty new to helping with staging etc | 21:50:50 |
| Grimmauld (any/all) | you probably don't have access yet. It also doesn't make much sense if we build the same thing on the same machine | 21:59:51 |
| Grimmauld (any/all) | 
Download image.png | 22:00:16 |
| winston | one more llvm build for the road | 22:00:23 |
| Grimmauld (any/all) | you can try to race it, but you probably won't beat the 80 cores there | 22:00:36 |
| winston | definitely won't 😆 | 22:00:50 |
| winston | i've been focusing on darwin because i've got a poor old ryzen 5 3600 and i actually wanna be able to work on other stuff while it builds | 22:01:20 |
| Grimmauld (any/all) | you can, in some builds. Its slow clock cycle, so it tends to lose on non-parallel builds. Also the disk is somewhat slow, so you can gain by putting your build dir in ram. But for LLVM, you won't beat paralellism | 22:01:58 |
| winston | also, i still have that strange build/test error on llvmPackages_20 | 22:02:25 |
| winston | might be best to repost that in #Nix on macOS | 22:02:38 |
| winston | * also, i still have that strange build/test error on llvmPackages_20 on aarch64-darwin | 22:02:46 |
| winston | guh i've also had nodejs fail on me like three times now because the firewall GUI keeps popping up while i'm ssh'd in or AFK | 22:13:40 |
| winston | on aarch64-darwin ofc | 22:13:54 |
