| 14 Dec 2024 |
 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 |
| Randy Eckenrode | More constructively, how does it interact with hooks? | 18:36:38 |
| Tristan Ross | It technically can support other compilers but personally, I intend it mostly for LLVM. | 18:36:49 |
| Randy Eckenrode | Rust makes heavy use of hooks to build packages. Capturing carious compilers in the hooks with a significant problem for Darwin. | 18:37:09 |
| Randy Eckenrode | * | 18:37:24 |
| Tristan Ross | In reply to @reckenrode:matrix.org
More constructively, how does it interact with hooks? It doesn't, a future pr will change how linkers are used so bintools and linkers are less connected. | 18:37:29 |
| Tristan Ross | The future PR will more explicitly set tooling. | 18:37:47 |
| Randy Eckenrode | This is more that rust.envVars.setEnv references stdenv.cc from various pkgsXY. You override the one in yours, but those remain as they were.0 | 18:38:41 |
| Randy Eckenrode | * This is more that rust.envVars.setEnv references stdenv.cc from various pkgsXY. You override the one in yours, but those remain as they were. | 18:38:46 |
| Tristan Ross | In reply to @reckenrode:matrix.org
Rust makes heavy use of hooks to build packages. Capturing carious compilers in the hooks with a significant problem for Darwin. Rust in particular with LLVM will have some changes in the future so it won't need the silly way it composes a new llvmPackages | 18:38:58 |
| Tristan Ross | I'm hoping to redo my CPU model PR as well to make CPU model changing work better between LLVM and GCC. | 18:40:22 |
| Tristan Ross | This is prerequisite work before I try an LLVM bootstrap. | 18:41:01 |
| 15 Dec 2024 |
| Tristan Ross | Huh, x86_64-unknown-linux-llvm was mentioned as a triplet which exists on the LLVM Discord server. I wonder if we could use that in the future. | 02:19:27 |
| Tristan Ross | It looks like we might be able to compile Nixpkgs for GPU's using an LLVM toolchain + libc. | 02:19:50 |
 Alyssa Ross | Redacted or Malformed Event | 09:07:39 |
| Tristan Ross | In reply to @philiptaron:matrix.org
https://pad.lassul.us/gYaWH4LuQGeED_BUSGInQA Been thinking, should we have a project board on GitHub? Something like Jira so we can organize and stage stuff. The pad you made made me think of it since it has a similar section. Plus it could make planning large changes easier. | 18:20:29 |
