| 17 Jan 2026 |
 Randy Eckenrode | https://github.com/NixOS/nixpkgs/blob/fa3fde27c743fe15cdd1d027795e50dcdb741995/pkgs/development/compilers/gcc/patches/default.nix#L35-L42 | 18:02:23 |
 alexfmpe | (not nixpkgs specific) | 18:02:25 |
| Randy Eckenrode | I wonder if I should just copy swift-frontend and swift-driver into the swift package and call it a day. | 18:03:56 |
| Randy Eckenrode | They both do their own resource folder logic. | 18:04:10 |
 emily | maybe that's another thing I have patches for locally | 18:16:18 |
| Randy Eckenrode | … does the current swift-driver not support separate lib outputs? | 18:18:04 |
| Randy Eckenrode | This is what I did. I think I know where I can patch it in both places, but I don’t want to break things that might depend on the path being resolved to the original binary. swift-driver is also pretty small. swift-frontend is inexplicably large. | 18:38:56 |
| Randy Eckenrode | * This is what I did. I think I know where I can patch it in both places, but I don’t want to break things that might depend on the path being resolved to the original binary. swift-driver is also pretty small. swift-frontend is inexplicably large though. | 18:39:04 |
| Randy Eckenrode | Copy all the things and let the store optimizer sort it out. | 18:39:24 |
| emily | assuming most users will only need to download the final package it shouldn't have much impact | 18:41:13 |
| emily | we could copy the stdlib in too if necessary | 18:41:28 |
| emily | although that means targetPlatform evil | 18:41:46 |
| Randy Eckenrode | The problem is swiftc looks for its libraries in the path where it really is. | 18:42:12 |
| Randy Eckenrode | So if swiftc is a symlink, it will look in the swiftc package, but that package has no stdlib. | 18:42:34 |
| Randy Eckenrode | What I want is for it to look in the swift package that symlinks all the stuff together. | 18:42:52 |
| Randy Eckenrode | swiftc, swift-driver, swift-corelibs-xctest, swift-testing, (on Linux), swift-corelibs-foundation, etc. | 18:43:23 |
| Randy Eckenrode | * swiftc, swift-driver, the stdlib, swift-corelibs-xctest, swift-testing, (on Linux), swift-corelibs-foundation, etc. | 18:43:49 |
| emily | right. unfortunate that that will involve targetPackages for a multi-target compiler but maybe we can figure something out with upstream one day | 18:44:14 |
| emily | how does their whole cross SDK stuff work upstream? | 18:44:31 |
| Randy Eckenrode | You specify --sdk <path to SDK>. | 18:45:15 |
| Randy Eckenrode | AFAIK | 18:45:16 |
| Randy Eckenrode | There are static Linux SDKs for various distros. | 18:45:27 |
| Randy Eckenrode | * | 18:45:48 |
| Randy Eckenrode | Supporting cross-compilation is a non-goal currently for my Swift work. It doesn’t currently work. Having the stdlib separate at least moves us in the right direction. | 18:47:13 |
| Randy Eckenrode | Right now I’m just looking for spliced packages in things that care about that. | 18:48:25 |
| Randy Eckenrode | https://github.com/reckenrode/nixpkgs/blob/139e88d5b9ed888bc534afcb981c4d79698fecb3/pkgs/by-name/sw/swiftPackages/by-name/sw/swiftc/package.nix#L61-L97 | 18:49:43 |
| Randy Eckenrode | If cross just happens to work, yay. I doubt it will, though we’re closer than we are currently. | 18:50:26 |
| emily | I was wondering whether we can avoid this "looking at its own location" by just putting that stuff in the SDK. | 18:51:47 |
| emily | then the SDK is a build input, a la apple-sdk. the compiler could propagate the ones for the host and target platforms | 18:52:45 |
| Randy Eckenrode | We would have to vend a special SDK on Darwin that adds the Swift libs the apple-sdk. | 19:30:39 |
