| 18 Dec 2025 |
 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 |
 emily | you can get Clang to print out default paths. I forget the flag. | 17:01:02 |
| emily | I bet it works for swiftc too. | 17:01:05 |
| emily | staticlib then :) | 17:01:14 |
| Katalin 🔪 | ah, hold on. here we go | 17:03:26 |
| Katalin 🔪 | Redacted or Malformed Event | 17:04:21 |
| Katalin 🔪 | ah no, it only looks for a /usr/include/Foo/module.modulemap which is for the clang modules | 17:06:08 |
| Katalin 🔪 | yeah, looks like no default module paths outside the toolchain dir | 17:06:17 |
| Katalin 🔪 | this is with strace so I might have missed something | 17:07:05 |
| Katalin 🔪 | (when you write 'import Foo', that is) | 17:07:26 |
| Katalin 🔪 | good to know in any case, since I will need to deal with this in Meson at some point when I do installable libraries | 17:11:14 |
| Randy Eckenrode | I was thinking there might be some pushback on the evil I’m doing. 😂 | 17:32:33 |
| Randy Eckenrode | I’m (ab)using dev because of the default lib.getDev done in make-derivation.nix. | 17:33:16 |
 Sarah Clark | People question: my Darwin PRs get merged the slowest. Is there anybody I should include in the review list? | 18:33:36 |
| Sarah Clark | (I'm focusing on Darwin fixes) | 18:34:07 |
| Sarah Clark | And a tech question: what's the best way to mark a package as broken on xx86_64-darwin? I'd use badPlatforms but recent PRs have been edited to use an inspect clause. | 18:43:30 |
| Sarah Clark | * And a tech question: what's the best way to mark a package as broken on x86_64-darwin? I'd use badPlatforms but recent PRs have been edited to use an inspect clause. | 18:44:21 |
 toonn | There's a lot fewer Darwin maintainers with commit bit so I'm afraid it's unavoidable. | 18:50:07 |
| Sarah Clark | sigh yeah. And I've seen several committers say they don't care about Darwin. | 18:52:38 |
| toonn | Not sure what an inspect clause is. I usually see branching on the platform, you could use that to set meta.broken. badPlatforms is semantically a bit different, it means "known not to build". Temporarily broken is not the same as not able to be built. | 18:56:07 |
| Randy Eckenrode | Probably something like lib.inspect.platforms.isDarwin or something like that. | 18:56:56 |
| Randy Eckenrode | You’d combine whatever the right one for Darwin is plus the one for x86_64z | 18:57:26 |
