| 13 Jan 2026 |
 Randy Eckenrode | Not sure. The swbuild tool uses its own command-line parser. It’s pretty funky. A custom frontend could just use Swift Argument Parser and delegate to the library for everything else. | 01:06:56 |
| Randy Eckenrode | This is a helper for keeping the boilerplate down. I don’t see how we can allow switching build systems in a hook. One of the keys to bootstrapping is not pulling in the wrong build system. | 01:09:29 |
| Randy Eckenrode | lib.getDev and lib.getOutput "dev" work as expected. What other ones are there? | 01:10:15 |
| Randy Eckenrode | Ideally, I could get prebuilts working and drop all this stuff. | 01:10:26 |
| Randy Eckenrode | I didn’t think so. It’s a temporary thing so I can keep the old Swift stuff around to reference while I work. The final PR will probably do it like Tcl does with tcl-modules.nix. | 01:11:36 |
| Randy Eckenrode | If I can, I can revisit using custom helper hooks I guess. I hate hooks because Bash sucks, and debugging them sucks. | 01:12:51 |
| Randy Eckenrode | More pressing right now is how exactly to handle stdlib discovery. | 01:14:38 |
 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 |
| Randy Eckenrode | “It also fixes the output of swift -frontend -print-target-info, which SwiftPM uses to set the rpath on Linux.”
If the .sos are in the normal place, won’t the linker take care of this for us?
| 01:21:27 |
| emily | is this about one of our existing patches? | 01:22:38 |
| emily | I figured you would have just thrown all of those away… | 01:22:45 |
| emily | I assumed -L would add to the rpath or such. | 01:23:42 |
| emily | not sure exactly how it works. | 01:23:44 |
| Randy Eckenrode | The separate lib patch. | 01:24:10 |
| emily | oh, our wrapper does it. | 01:24:37 |
| emily | # Three tasks:
#
# 1. Find all -L... switches for rpath
| 01:24:40 |
