| 2 Feb 2026 |
 Randy Eckenrode | aaaaaaaaaaaaah | 00:55:27 |
| Randy Eckenrode | I’ve been trying to make sure that Swift uses the real path to the stdlib when it sets the rpath. Apparently it’s mpv’s Meson that does that. | 00:55:57 |
| Randy Eckenrode | Blah | 00:55:58 |
| Randy Eckenrode | My code seems to work though. If you use the hidden -toolchain-stdlib-rpath argument, it resolves the rpath to the stdlib path of /nix/store/ss85ygcfnr99yjdk23li8v8s56ngvcl3-stdlib-6.2.3-dev/lib/swift/macosx. Which is wrong, but its heart is in the right place. | 00:58:29 |
| Randy Eckenrode | I patched the mpv derivation to use the right path. I’m going to punt on fixing the above until it affects the Linux build. | 03:13:49 |
| Randy Eckenrode | Before doing that, I want to revist the Swift package stuff. It’s too magic. I’m thinking now of just putting stuff in an attribute that you reference, so to set up SwiftPM, you add foo-package.sdist or something to buildInputs. | 03:14:47 |
| Randy Eckenrode | Is there any precedent for doing a vendor tarball as a derivation for each piece of the tarball? | 03:15:03 |
| Randy Eckenrode | I am also considering reintroducing fetchSwiftPMDeps or something to that effect. | 04:29:41 |
 debtquity | oooh, the swift compiler error is fixed, yay | 04:43:33 |
