| 13 Jan 2026 |
 emily | that would be nice for sure. what was the issue with that again? | 01:14:38 |
 Randy Eckenrode | It requires figuring out how it works and (probably) patching SwiftPM to allow it. | 01:14:56 |
 samasaur | aren't they only recently officially supported for swift-syntax only? | 01:15:14 |
| samasaur | and no support for any other package | 01:15:20 |
| Randy Eckenrode | There is some magic for Swift Syntax, but it seems to be really brittle. I was able to get it to parse a prebuilts entry in workspace-state.json, but SwiftPM didn’t do anything with it. | 01:15:31 |
| Randy Eckenrode | The more pressing need is figuring out how to discover the stdlib. | 01:15:47 |
| Randy Eckenrode | The current approach patches the compiler to find it at an arbitrary path, which isn’t very good for cross-compilation. | 01:16:19 |
| emily | env variable? | 01:16:35 |
| Randy Eckenrode | Ideally we could leverage the compiler’s ability to discover the stdlib relative to its location. | 01:16:48 |
| emily | preferably target-specific env variable | 01:16:48 |
| emily | though, yeah, avoiding patching at all is nicer | 01:17:01 |
| emily | can we just symlink the compiler and the stdlib nearby? | 01:17:11 |
| Randy Eckenrode | That’s what I want to do, but I also want them to be discoverable by the linker. | 01:18:28 |
| Randy Eckenrode | How does it work on Linux? Does linking with a .so at some path automatically set up the rpath? | 01:18:44 |
| Randy Eckenrode | It makes me wonder what even the point of the patch is if the linker will handle things for us. | 01:20:35 |
