Apple: tvOS, visionOS support; use unified build container#159
Conversation
stuartcarnie
changed the title
* 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
Changes variable from `SWIFT_FRONTEND` to `SWIFT_COMPILER` Requires rsanchezsaez/godot#15
| # Link config for macOS: | ||
| # -fuse-ld=lld — use LLD (not cctools-port ld, which our | ||
| # image doesn't install and whose `.tbd` | ||
| # parsing pulls in the libtapi dependency). | ||
| # -B /opt/darwin-tools/bin — prepend darwin-tools to clang's program | ||
| # search so `-fuse-ld=lld` resolves to the | ||
| # Apple-platforms-enabled ld64.lld there | ||
| # (swiftly's bundled lld has Apple platforms | ||
| # disabled at build time). | ||
| # -L .../XcodeDefault.xctoolchain/usr/lib/clang/21/lib/darwin -lclang_rt.osx | ||
| # — Apple's compiler-rt from Xcode, providing | ||
| # __isPlatformVersionAtLeast for | ||
| # `if (@available(...))` / `__builtin_available`. | ||
| # Apple's clang driver auto-links this on | ||
| # macOS; osxcross-style cross-builds have to | ||
| # wire it up explicitly. | ||
| XCODE_CLANG_RT="/root/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/lib/darwin" | ||
| EXTRA_LINKFLAGS="linkflags=-fuse-ld=lld -B /opt/darwin-tools/bin -L${XCODE_CLANG_RT} -lclang_rt.osx" | ||
|
|
There was a problem hiding this comment.
Can this be added in upstream Godot's platform/macos/detect.py in some way?
Those build scripts aren't meant to have a lot of custom code compared to just configuring the build with standard SCons options we provide.
There was a problem hiding this comment.
I'd argue these flags are internal details specific to this build container version, so I'd rather not leak them out to the scons script. Otherwise every time I change / improve this container, I'd also have to change the scons scripts in Godot. There is already some leakage, but at least today it is fairly minimal.
My longer-term goal is to keep chipping away at these internal hacks so they aren't necessary.
There was a problem hiding this comment.
You can put these in the actual container as pre-set environments. That would be far preferable over having it in the build scripts. The build scripts themselves shouldn't depend on very specific versions of stuff in the containers.
For mono we also used to do that. Just add these to the environment in the container that actually has these versions installed!
|
I'll merge this now to match godotengine/build-containers#163 which I merged earlier, but I'd like to see the outstanding review comments handled in a follow-up pair of PRs to build-containers and godot-build-scripts, so we can clean up further and prepare new build containers for 4.8-dev2. |
4 participants
Depends on:
Testing