| 13 Dec 2024 |
 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 |
| Randy Eckenrode | In reply to @rosscomputerguy:matrix.org
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. It’s propagated by the autotoolsHook that you add? | 18:25:08 |
| Tristan Ross | Not everything uses autotools | 18:25:35 |
| Randy Eckenrode | That’s an example. Meson, CMake, whatever. Default stdenv should be the same as stdenvNoCC. | 18:26:19 |
| Randy Eckenrode | Explicit over implicit dependencies. | 18:26:30 |
| Tristan Ross | We probably could experiment in the future with going stdenvNoCC by default. | 18:27:23 |
| Tristan Ross | But it's probably not an important thing to do right now. | 18:27:44 |
| Randy Eckenrode | Yeah. I’d also want to look at some of the proposals for handling cross-compilation. | 18:29:00 |
| Randy Eckenrode | There’s too much magic happening right now, which is the thing I dislike. As soon as the magic stops working (or can’t be used), it gets harder to do the right thing. | 18:29:54 |
| Randy Eckenrode | My only concern with making it easier to swap out tooling is support burden. I assume this is aimed at package authors not users? | 18:31:41 |
| Randy Eckenrode | Because I absolutely do not want to waste time supporting users who want to build their Darwin packages with weird compilers/linkers/etc. | 18:32:16 |
| Tristan Ross | The switching out of compilers in the PR I made is primarily intended for LLVM and Linux. | 18:36:16 |
