| 13 Apr 2026 |
 niklaskorz | the swift-build README states it's used in Xcode which answers your first question I guess | 09:56:39 |
 viraptor | Ok, it does indeed do the things, I was looking in the wrong repo - it's effectively a plugin. | 10:51:20 |
| viraptor | actool is updated now, feel free to test. I'll get it in nixpkgs later | 10:52:06 |
| viraptor | Digging deeper - turns out it's not https://github.com/swiftlang/swift-build/blob/df624d19606034a214393ecab6baac937518746e/Plugins/run-xcodebuild/run-xcodebuild.swift#L45 it just calls out to xcodebuild through xcrun, so it still depends on Xcode | 11:50:25 |
| niklaskorz | indeed, looks like xcodebuild does the project parsing and then forwards the information to swift-build in the PIF format described here:
https://github.com/swiftlang/swift-build/blob/main/SwiftBuild.docc/Core/project-interchange-format.md | 12:06:59 |
 Randy Eckenrode | I have used swbuild in a derivation to (try to) build an Xcode protect. | 12:22:08 |
| Randy Eckenrode | https://github.com/swiftlang/swift-build/issues/43
That plugin appears to be for running xcodebuild with (your built) Swift Build service.
| 12:23:42 |
| Randy Eckenrode | https://github.com/NixOS/nixpkgs/pull/477520#issuecomment-3764540038 | 12:25:44 |
| Randy Eckenrode | It failed due to missing yet another proprietary tool. | 12:25:56 |
| viraptor | Thank you very much. The docs for that project are quite poor - I'm really happy you found more details already! | 12:30:20 |
| viraptor | Hmmm... It's just processing a plistxml to generate some scaffolded interfaces. "How hard could that be" feeling is growing... | 12:38:37 |
| viraptor | * | 12:39:10 |
| Randy Eckenrode | I can’t make progress on the ICU issue until I resolve the issue with linking the 26.4 SDK using ld64. | 13:32:22 |
 ankarhem | Do you know if there’s some workaround we can do locally for dotnet until it’s properly fixed? | 13:43:33 |
 toonn | Applying Randy's PR is probably the best workaround IMO. | 13:47:24 |
| Randy Eckenrode | That’s probably the best approach right now. | 13:47:59 |
| Randy Eckenrode | I can rebase my changes on master, but I won’t be able to do that until lunch. I’m currently on my staging/Swift branch. | 13:53:42 |
| niklaskorz | I looked into the idea of merging the normal icu package's dylibs into one libicucore.dylib this morning, but:
- that requires rebuilding anyway because it has to be built with symbol renaming disabled for programs that expect libicucore.dylib (either that or dotnet has to be patched to not disable icu symbol renaming on macOS)
- with symbol renaming disabled, I ended up with a "SIGBUS 10" crash
| 15:35:35 |
| Randy Eckenrode | Symbol renaming being disabled should be the default. How were
you merging? | 15:36:53 |
