| 12 Dec 2024 |
 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 |
| Randy Eckenrode | In reply to @rosscomputerguy:matrix.org
I'm not sure I understand what you mean. Maybe I’m misunderstanding, but is the proposal to change compiler by specifying it in the attrset (e.g., cc = "clang")? | 14:52:42 |
| Randy Eckenrode | In general, I don’t like how C is given a privileged position in the stdenv. I would rather that you have to add, e.g., autotoolsHook to build an autotools package just like you would one using Meson or CMake or cargo or whatever. | 14:53:50 |
| Tristan Ross | In reply to @reckenrode:matrix.org
Maybe I’m misunderstanding, but is the proposal to change compiler by specifying it in the attrset (e.g., cc = "clang")? Yeah, that's how you can switch out the compiler. But you can change the toolchain using the toolchain attribute. The idea is to prevent things from not applying right in pkgs/stdenv/cross/default.nix. Before, it would depend on the order of the if statements. Now, since it's like an enum it would work better. Stacking different pkgs* works better now because of the changes. | 14:57:55 |
| Tristan Ross | In reply to @reckenrode:matrix.org
In general, I don’t like how C is given a privileged position in the stdenv. I would rather that you have to add, e.g., autotoolsHook to build an autotools package just like you would one using Meson or CMake or cargo or whatever. I'm not sure how we can have an stdenv without including CC for C packages. Including it probably makes the amount of copying and passing less because there are less duplicate lines. | 14:59:27 |
