| 31 Oct 2025 |
 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 |
| niklaskorz | so I'm still not sure if that either just doesn't work or I'm looking in the wrong place | 09:51:43 |
| niklaskorz | diff --git a/pkgs/stdenv/cross/default.nix b/pkgs/stdenv/cross/default.nix
index cc53957eee0d..15f76c9fbe53 100644
--- a/pkgs/stdenv/cross/default.nix
+++ b/pkgs/stdenv/cross/default.nix
@@ -69,6 +69,7 @@ lib.init bootStages
extraNativeBuildInputs =
old.extraNativeBuildInputs
++ lib.optionals (hostPlatform.isLinux && !buildPlatform.isLinux) [ buildPackages.patchelf ]
+ ++ lib.optionals (buildPlatform.isDarwin && !hostPlatform.isDarwin) [ buildPackages.apple-sdk ]
++ lib.optional (
let
f =
| 09:51:52 |
| niklaskorz | this doesn't fix the build issue unfortunately, same result as before | 09:52:04 |
| niklaskorz | also there generally is no way to pass RUSTFLAGS to the build script compilation it seems | 10:06:52 |
| niklaskorz | a PR in 2017 was rejected: https://github.com/rust-lang/cargo/pull/4428 | 10:07:00 |
| niklaskorz |
The flag is not passed to all compiler instances: When cross-compiling (i.e., when --target is set), the flag is not passed to build scripts. It seems there is currently no way to pass anything to build scripts when --target is set, which clearly is a feature gap.
| 10:07:27 |
