| 12 Dec 2024 |
 Artturin | not yet in master | 20:31:56 |
 truby | ah ok. Anything I can do to work around that? "just use staging"? :) | 20:32:19 |
| truby | If this was fixed before in master and the fix was removed for a version bump, why is the removal of the fix in master while the fix is still in staging? Sorry if this is a naieve question 😅 | 20:35:29 |
 Philip Taron (UTC-8) | All: Please edit away, or post on behalf of the team Tristan Ross | 20:37:30 |
| Artturin | In reply to @truby:matrix.org
If this was fixed before in master and the fix was removed for a version bump, why is the removal of the fix in master while the fix is still in staging? Sorry if this is a naieve question 😅 The creator of https://github.com/NixOS/nixpkgs/pull/360044 put it in the wrong branch | 20:45:01 |
| truby | I do seem to be getting further after pinning to the parent of that commit :) | 21:00:19 |
| 13 Dec 2024 |
 Tristan Ross | I'm curious as to why we do use${compiler} to change the compiler out instead of something like cc = "clang". I probably could work on a PR to do that. It probably would work better with composing with the other various pkgs. | 18:17:54 |
 sterni | More often than not, swapping out things doesn't work individually useLLVM for example implies some sort of whole LLVM toolchain. | 22:17:42 |
| sterni | The weird API is because the implicit assumption is of course that every platform has its own toolchain and not multiple alternative ones | 22:18:20 |
| sterni | Ideally we'd allow switching out things individually, but there are limits e.g. clang and GNU binutils only work together to an extent (only C, no LTO) | 22:18:53 |
| sterni | Tristan Ross: If you want to start on this, I'd recommend you'd try to wire up linker. That is a plain string in the platform set, but changing it doesn't do anything. It's just informational, telling you what the linker is, but it doesn't change anything if you set it explicitly | 22:20:05 |
| sterni | (at least as far as I recall, maybe it just was that linker = "ld.gold" doesn't do anything | 22:20:32 |
| sterni | * (at least as far as I recall, maybe it just was that linker = "ld.gold" doesn't do anything) | 22:20:37 |
| Tristan Ross | In reply to @sternenseemann:systemli.org
More often than not, swapping out things doesn't work individually useLLVM for example implies some sort of whole LLVM toolchain. Yeah, I kinda thought about it more while driving to my grandma's. | 22:31:24 |
| Tristan Ross | We probably could have multiple flags with an encompassing one | 22:31:38 |
| Tristan Ross | toolschain, cc, linker, and bintools | 22:31:50 |
| Tristan Ross | My hope is to make nixpkgs more flexible with possible options and ways you can tune it or modify the compilation. | 22:40:59 |
| Tristan Ross | We have the ability to make it possible so why not have it as an actual feature. | 22:41:17 |
| Tristan Ross | Improving the UX on changing the compilers might be the first thing before I start work towards a pure LLVM Linux toolchain. | 22:41:54 |
| Tristan Ross | * Improving the UX on changing the compilers might be the first thing before I start work towards a pure LLVM Linux bootstrap. | 22:42:06 |
| Tristan Ross | https://github.com/NixOS/nixpkgs/pull/365057 | 23:58:40 |
| 14 Dec 2024 |
| Tristan Ross | Randy Eckenrode: I get a Darwin CI failure with infinite recursion and I'm not familiar enough with Darwin to fix it. Any ideas? | 00:15:03 |
| Tristan Ross | Oh, I fixed it | 00:19:50 |
| Tristan Ross | I accidentally used *Platform.cc instead of *Platform.toolchain | 00:20:15 |
| Tristan Ross | So it must've included a dependency badly in the wrong stage | 00:20:33 |
 Randy Eckenrode | I would rather the stdenv not have compilers than to double down by wiring more compiler assumptions into it. | 00:26:26 |
| Tristan Ross | I'm not sure I understand what you mean. | 00:32:01 |
| Tristan Ross | https://github.com/NixOS/nixpkgs/pull/364050 we probably should get this done | 05:56:15 |
| truby | I managed to get my environment with libcxxStdenv and C++ dependencies built with libc++ working, but I had a few issues that I think might need fixing; I am not sure why I have to specify clang-scan-deps here like this, and can't just use llvmPackages.clang-tools. I've had this issue before when switching to a newer GCC version too (that the wrong gcc stdlib is selected).
Also, cmake can't find clang-scan-deps automatically, I have to pass -DCMAKE_CXX_COMPILER_CLANG_SCAN_DEPS=clang-scan-deps, even though it's on my path. Not sure why exactly that's happening. | 14:49:55 |
| truby | Anyone got ideas here? I mean at least it works now, so I'm happy with that 😄 | 14:50:29 |
