| 16 Dec 2025 |
 Randy Eckenrode | I really wish SwiftPM had a way to provide pre-built artifacts for these, but AFAIK it does not. The intent is you build everything from source. | 12:41:02 |
| Randy Eckenrode | I may go back to the drawing board and provide a binary output that actually does the build, so things that use SwiftPM can still build right. | 12:41:44 |
| Randy Eckenrode | I do want to hack up Swift PM to make it use our toolchain’s binaries for the experimental Swift Syntax binaries flag, but I still need to separate them out. | 12:42:27 |
| Randy Eckenrode | I’m currently grinding through getting SwiftPM building. I want the result to look like what it would if build by SwiftPM. The CMake files do not seem meant for production use …. | 12:43:25 |
|  vic set their display name to oeiuwq. | 15:10:07 |
| vic set a profile picture. | 21:32:12 |
| vic changed their display name from oeiuwq to vic. | 21:32:21 |
| 17 Dec 2025 |
| Randy Eckenrode | Does ${!outputInclude} not actually work? | 02:50:37 |
| Randy Eckenrode | $ echo $outputInclude
out
$ echo ${!outputInclude}
/Users/reckenrode/Developer/nixpkgs/outputs/out
$ echo ${!outputs[@]}
include lib out
$ echo ${outputs[include]}
/Users/reckenrode/Developer/nixpkgs/outputs/include
| 02:50:58 |
| Randy Eckenrode | dev is reserved for evil hacks. mkSwiftPackage adds a passthru.dev that vendors the patched source for use with SwiftPM. | 02:51:32 |
|  @azuwis:matrix.org left the room. | 07:06:15 |
 Ihar Hrachyshka | I posted a PR forcing darwin in electron* meta.platforms on Linux: https://github.com/NixOS/nixpkgs/pull/471643 so that hydra etc. knows it supports darwin. It's not very pretty (uses overrideAttrs) but I'm not ready to fix darwin source build of electron. any major reservations against this approach? | 18:08:32 |
| 18 Dec 2025 |
| Randy Eckenrode | Any Swift people have thoughts on where libraries should be installed? emily Katalin 🔪 samasaur WeetHet | 16:49:31 |
| Randy Eckenrode | I’m currently putting them in ${!outputLib}/lib, but Swift packages have various ideas about where they want to put them. | 16:50:11 |
| Randy Eckenrode | Modules are installed separately, currently. | 16:50:32 |
 Katalin 🔪 | that's where I'd put them too | 16:50:37 |
| Katalin 🔪 | and modules in include/ | 16:50:44 |
| Katalin 🔪 | where do other packages want to put them? | 16:51:21 |
| Randy Eckenrode | Some install scripts put them in lib/swift or lib/swift/${swift_os}. | 16:52:38 |
| Randy Eckenrode | With swift_static for static libraries. | 16:52:56 |
 emily | does SwiftPM have opinions? | 16:54:24 |
| emily | what do Linux distros do? | 16:54:30 |
| Randy Eckenrode | It doesn’t support installation. | 16:54:38 |
| emily | lib/swift makes some sense to me since it matches the SDK | 16:54:50 |
| emily | what are example filenames that go in there? | 16:54:58 |
| Katalin 🔪 | hmmm, I wouldn't separate them since they are generally normal libraries and I assume nix won't build static and shared libraries at the same time either | 16:55:21 |
| Randy Eckenrode | For their own packages? I don’t know. They seem out of date. The official tarballs seem to statically link everything except for the toolchain/stdlib libs. | 16:55:23 |
| Randy Eckenrode | Share libraries, static libraries, Swift modules. | 16:55:45 |
| emily | so normal libfoo.dylib? | 16:55:52 |
| Randy Eckenrode | Pretty much. | 16:56:01 |
