| 31 Oct 2025 |
 niklaskorz | ok so then it makes sense that is being compiled for the build platform | 13:37:26 |
| niklaskorz | hm but in that case emily's original suggestion is likely the solution and I just added it in the wrong place | 13:38:30 |
| niklaskorz | at least I'm now certain it fails for cc crate with feature parallel enabled | 13:52:59 |
 Randy Eckenrode | Shouldn’t the build platform CC have the right SDK and stuff? It should be using the fallback SDK. | 13:55:02 |
| Randy Eckenrode | Oh, but it’s not finding the propagated inputs probably. If you add just libiconv, does it work? | 13:56:53 |
| Randy Eckenrode | I hate how we do dependencies so much. | 13:57:02 |
| Randy Eckenrode | Like with a bunch of wrapper stuff and Bash to find propagated dependencies. | 13:57:50 |
| niklaskorz | no, already tried that :/ | 13:58:44 |
| Randy Eckenrode | Maybe we should symlink the dylibs or add text-based stubs for them instead of propagating them. I can do that for 26.05. It seems too risky for 25.11. | 13:59:08 |
| Randy Eckenrode | I don’t think adding an SDK for the build platform is the right solution. | 13:59:31 |
| Randy Eckenrode | * | 13:59:46 |
| Randy Eckenrode | Or maybe it is but only when Darwin is the build. 🤔 | 14:00:25 |
| niklaskorz | uploaded the minimal reproducer here: https://github.com/niklaskorz/nix-rust-cross-cc | 14:00:29 |
 K900 | https://www.lunarg.com/lunarg-achieves-vulkan-1-3-conformance-with-kosmickrisp-on-apple-silicon/ wow | 15:05:43 |
 emily | we should just add apple-sdk to extraNativeBuildInputs I'm pretty sure | 15:43:10 |
| emily | it's redundant on native but the right thing for cross | 15:43:19 |
 Ihar Hrachyshka | is there a ready module for ssh-agent like the one in hm but launchd compatible? | 22:11:55 |
| 1 Nov 2025 |
 samasaur | https://www.swift.org/build-and-packaging-workgroup/ | 00:19:43 |
| samasaur | seems like that workgroup is not actually about packaging swift itself but it's still nice that there is now an actual group working on the build tooling | 00:20:39 |
| samasaur | we technically fall under this responsibility:
work with the community to support tooling outside the Swift project
| 00:21:44 |
| samasaur | though that is a generous reading on my part | 00:21:54 |
| Randy Eckenrode |
Decisions about how components of the Swift toolchain itself are built and distributed fall outside the workgroup’s charter.
| 00:22:11 |
| samasaur | hmm | 00:22:47 |
| Randy Eckenrode | It seems like this is about build system integration and how to help them with things like dependency resolution? | 00:23:07 |
| samasaur | so (if helpful at all) would be more helpful for your swift package set work, perhaps? | 00:23:24 |
| samasaur | i wonder if there is a working group for packaging the toolchain itself | 00:23:37 |
| Randy Eckenrode | Maybe, but the way Nix does things is an impediment. | 00:29:09 |
 Katalin 🔪 |
Encourage development of Swift integrations in existing build and packaging systems that are outside of the Swift project (e.g. CMake, Bazel)
this is really cool to see :^) | 00:30:54 |
| Katalin 🔪 | especially since I'm working on making Swift support in Meson better | 00:32:08 |
| Katalin 🔪 | but also just in general | 00:32:15 |
