| 13 Apr 2026 |
 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 |
| Randy Eckenrode | I’m using clang++ to relink the dylibs. Make sure you also relink libicutu.dylb against libicucore.dylib. | 15:37:32 |
| Randy Eckenrode | * I’m using clang++ to relink the dylibs. Make sure you also relink libicutu.dylib against libicucore.dylib. | 15:37:45 |
| Randy Eckenrode | Finished my (attempted) build against master. It also crashed. Looking at the stack trace, it’s crashing in the same place. | 23:38:39 |
| 14 Apr 2026 |
| viraptor | Is swbuild available somewhere for testing already? I'm assuming you weren't using the host one in that PR. | 01:31:34 |
| viraptor | * | 01:40:58 |
| viraptor | * | 01:43:10 |
| Randy Eckenrode | It’s in my swift-update-mk2 branch. | 02:10:26 |
|  LogN [unavailable @ CinemaCon -> 4/18] changed their display name from LogN to LogN [unavailable @ CinemaCon -> 4/18]. | 04:03:07 |
 eveeifyeve | Can you enable homebrew for multiple users or don't declare a user? | 09:53:07 |
| eveeifyeve | Because I am writing my config using the dendritic pattern, I have a problem where I will require multiple users so I need it to be either user specific or global defination. | 09:54:18 |
| eveeifyeve | * Because I am writing my config using the dendritic pattern, I have a problem where I will require multiple users so I need it to be either user specific or global definition. | 09:54:26 |
| eveeifyeve | There isn't exact primaryUser in this case. | 09:54:58 |
