Apple: simplified build system for all platforms - #163
Conversation
* single build container for all platforms * visionOS+tvOS support * SDK 26.4 Container is smaller and builds significantly faster
* single build container for all platforms * visionOS+tvOS support * SDK 26.5 * Latest Swift 6.3.2 Container is smaller and builds significantly faster Apple: tvOS,visionOS support; use unified apple container
|
I have tested this (and the related PR on Before this PR, I was having issues building the iOS export templates, but it seems to work now although I haven't actually tested using the templates. This could just be a environment issue on my side, not related to this change at all. I did get some warnings in the logs. I'm not sure if this is my setup's fault so I'll post the full logs here just in case. The warnings mention something about not finding clang intrinsic headers and that it should be reported to the OSXCross project. I also had to comment out the part about notarization because it seems the |
|
@raulsntos those warnings are currently expected, but don't affect the compiled output. Thanks for testing! |
> [!NOTE] > > Once 6.4 is released, I'll remove the < 6.4 hacks
ed6ccd3 to
36137c5
Compare
Changes variable from `SWIFT_FRONTEND` to `SWIFT_COMPILER` Requires rsanchezsaez/godot#15
NOTE: The Xcode 26.6 .xip file wasn't readable by xar 1.8, so `xip_extract_content.py` was introduced to extract the `Content` that is passed into `pbzx`.
swiftly installs a dispatcher for all the toolchain binaries, clang++, swiftc, etc. This dispatcher spawns ~17 threads just to resolve the real clang++, swiftc in the toolchain binary path, resulting in an excessive number of threads on the build box (with 64 cores), causing it to hit the default 2048 limit and failing.
akien-mga
left a comment
akien-mga
left a comment
There was a problem hiding this comment.
Tested successfully, it seems to work great!
I haven't reviewed everything in depth in the shell scripts and Dockerfile.apple, but it seems relatively straightforward and confirmed to work well.
|
Thanks for the amazing work on this BTW, it's a major improvement to our build pipeline! ❤️ |
akien-mga
left a comment
akien-mga
left a comment
There was a problem hiding this comment.
Found some time, so belated review of the new container.
| # * dsymutil — dSYM generation | ||
| # * libtool — llvm-libtool-darwin (Darwin-format static archiver) | ||
| # | ||
| # Pinned to v1.0.1 (Dec 2024, LLD 20 from swiftlang/llvm-project). |
There was a problem hiding this comment.
It's not super clear here, but I guess it's only pinned to that old version because it's the last one on https://github.com/xtool-org/darwin-tools-linux-llvm, not because newer version wouldn't work.
| # Godot's platform/{ios,tvos,visionos}/detect.py composes compiler and | ||
| # archiver paths as `${APPLE_TOOLCHAIN_PATH}/usr/bin/${apple_target_triple}<tool>`. | ||
| # The existing build-{ios,tvos,visionos}/build.sh scripts set | ||
| # APPLE_TOOLCHAIN_PATH=/root/ioscross/<arch> | ||
| # apple_target_triple=<prefix>-apple-darwin11- | ||
| # inherited from the old cctools-port wrapper layout. |
There was a problem hiding this comment.
Sounds like we could simplify things here and just not use the old darwin11 triple in build scripts?
There was a problem hiding this comment.
Yes, those are gone now from the upgrades scripts
5 participants
Important
We should use the 6.4.x-snapshot-2025-06-11 for all builds, as those are still official releases from Apple
godot-apple:<image version>for all Apple platformsAPPLE_LLVM_CROSS=1--build-arg swift_version=6.4.x-snapshot-2026-06-11-fno-objc-msgsend-selector-stubs -Wno-unused-command-line-argumentAs a win, building a single container for all Apple platforms is significantly faster 🚀
Depends on: