| 18 Dec 2025 |
 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 |
| emily | what are modules like? | 16:56:07 |
| Katalin 🔪 | what does CMake do? | 16:56:10 |
| emily | & where does the compiler search for libraries on FHS distros? | 16:56:16 |
| Katalin 🔪 | modules generally behave like C headers | 16:56:31 |
| Randy Eckenrode | Whatever the project tells it to do. | 16:56:38 |
| Katalin 🔪 | ah. (: | 16:56:43 |
| Randy Eckenrode | Swift build expects to vendor everything. With traits (like Cargo features), you can’t really pre-build libraries anymore. | 16:57:18 |
| emily | FWIW static libraries should really go in ${!outputDev}/lib IMO, or perhaps even a staticlib output. the reason we don't do that is because build systems are dumb. if it can be achieved for Swift it should be | 16:57:35 |
| Randy Eckenrode | I’m doing it here for the CMake builds needed by the toolchain. | 16:57:49 |
| emily | the lib output should be stuff required at runtime, which static libraries (and modules?) never are | 16:57:51 |
| Katalin 🔪 | and the compiler i.e. swiftc? | 16:58:00 |
| Katalin 🔪 | I'm currently looking but I don't know if you can get it to print a default include path | 16:58:11 |
| Katalin 🔪 | there's -Isystem and -I | 16:58:19 |
| Katalin 🔪 | like on a normal C compiler | 16:58:27 |
| Randy Eckenrode | I think swiftc probably doesn’t look beyond its toolchain location. | 16:58:38 |
| Randy Eckenrode | * I suspect swiftc probably doesn’t look beyond its toolchain location. | 16:58:47 |
| Randy Eckenrode | It supports being told where, which is what SwiftPM and CMake both do. | 16:59:06 |
| Randy Eckenrode | dev is not available for Swift packages due to some evil stuff I am doing to make `buildInputs = [ swift-foo ];‘ do something sensible with SwiftPM. | 17:00:15 |
| Katalin 🔪 | ah yeah that would make sense, I guess that's how it works with the Xcode toolchain too since that contains everything | 17:00:26 |
| Randy Eckenrode | * dev is not available for Swift packages due to some evil stuff I am doing to make buildInputs = [ swift-foo ]; do something sensible with SwiftPM. | 17:00:26 |
| Katalin 🔪 | it doesn't have /usr/include as a default path at least from a quick test | 17:00:36 |
| Randy Eckenrode | Otherwise, I agree. I’m (ab)using include for CMake files and Swift modules. | 17:01:01 |
