| 22 Jan 2026 |
 Ivy | how can we sign binaries on macos? and applications? | 02:44:41 |
| Ivy | okay how the hell are we meant to get metal working | 11:04:34 |
| Ivy | or is it fundamentally impossible | 11:04:48 |
 K900 | I think it should be in stdenv? | 11:06:22 |
| K900 | Along with the rest of the SDK | 11:06:26 |
| Ivy | i dont think it is? | 11:08:02 |
| Ivy | error: tool 'metal' not found | 11:08:34 |
| K900 | I think the libraries are available but the CLI tool isn't because we can't redistribute it | 11:10:43 |
| Ivy | ahh i see | 11:11:16 |
| Ivy | how do we get the cli tool then? | 11:11:24 |
| K900 | AFAIK the answer is "you don't" | 11:11:56 |
| K900 | But I may not be up to date on the state of the art | 11:12:03 |
| Ivy | okay utter collapse for ghostty then | 11:13:58 |
| Ivy | cause thats where ive gotten stuck building with nix | 11:14:10 |
| Ivy | https://github.com/ghostty-org/ghostty/blob/1003a7e62209ef78895b3bb03b82ad345bec1965/src/build/MetallibStep.zig#L54-L67 | 11:14:45 |
| Ivy | these lines run metal to produce ir | 11:14:53 |
| Ivy | as i've patched the other problems to not need ios toolchain | 11:15:19 |
| Ivy | compile lib ghostty ReleaseFast aarch64-macos.13.0 transitive failure
| +- metallib Ghostty (Ghostty.metallib) transitive failure
| | +- metal Ghostty (Ghostty.ir) failure
| | +- metal Ghostty (Ghostty.ir) (reused)
| +- WriteFile props.zig (+2 more reused dependencies)
| +- WriteFile props.zig (+2 more reused dependencies)
| +- metallib Ghostty (Ghostty.metallib) (+2 more reused dependencies)
| +- WriteFile props.zig (+2 more reused dependencies)
| +- WriteFile props.zig (+2 more reused dependencies)
| +- run exe uucode_build_tables (tables.zig) (+1 more reused dependencies)
| +- run exe uucode_build_tables (tables.zig) failure
+- compile lib ghostty ReleaseFast aarch64-macos.13.0 (+6
| 11:19:35 |
| Ivy | where im able to get this far | 11:19:41 |
| Ivy | but it requires compilation of shaders | 11:32:10 |
 Randy Eckenrode | Signing with a developer cert isn’t really supported. | 11:40:59 |
| Randy Eckenrode | Disable pre-compilation or compile them offline and vendor the resulting files. | 11:41:39 |
|  @enzime:nixos.dev left the room. | 15:02:09 |
| 23 Jan 2026 |
| Randy Eckenrode | My current thinking on handling the stdlib is to make Swift first look for an environment variable NIX_STDLIB_RUNTIME_${swift_tuple} then fall back to looking by path. However, I need to dig into the Swift code to make sure that is possible. If so, it would allow for multiple, target-dependent stdlibs to Just Work™. | 01:11:17 |
| Randy Eckenrode | * My current thinking on handling the stdlib is to make Swift first look for an environment variable NIX_SWIFT_STDLIB_RUNTIME_${swift_tuple} then fall back to looking by path. However, I need to dig into the Swift code to make sure that is possible. If so, it would allow for multiple, target-dependent stdlibs to Just Work™. | 01:11:37 |
| Randy Eckenrode | Note: No NIX_SWIFT_STDLIB_RUNTIME_FOR_BUILD or FOR_TARGET stuff. The tuple will be a platform property that the stdlib’s hook will use to set the variable. | 01:12:13 |
| Randy Eckenrode | That should allow me to avoid wrappers and allow the same swiftc to support multiple -target platforms. | 01:12:37 |
| Randy Eckenrode | It would be nice if we can set those up like the SDK, but I’m skeptical, and it doesn’t work right for Darwin due to having multiple SDKs (the Swift stdlib and the standard, Apple one). | 01:13:18 |
| Randy Eckenrode | * My current thinking on handling the stdlib is to make Swift first look for an environment variable NIX_SWIFT_STDLIB_RUNTIME_${swift_triple} then fall back to looking by path. However, I need to dig into the Swift code to make sure that is possible. If so, it would allow for multiple, target-dependent stdlibs to Just Work™. | 01:51:34 |
| Randy Eckenrode | I am going to explore SDKs though. There is some neat stuff with toolchains, but will it work? | 01:51:46 |
