build: respect config.emit_xcframework for building libghostty-vt.xcframework on Darwin#12267
Conversation
|
Hi @0xDVC, thanks for your interest in contributing! This project requires that pull request authors are vouched, and you are not in the list of vouched users. This PR will be closed automatically. See https://github.com/ghostty-org/ghostty/blob/main/CONTRIBUTING.md for more details. |
|
!vouch |
Triggered by [comment](#12267 (comment)) from @mitchellh. Vouch: @0xDVC Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Triggered by [comment](ghostty-org#12267 (comment)) from @mitchellh. Vouch: @0xDVC Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
|
We've got some CI failures, we should look into it. I thought our swift example should have xcode and we should default emit xcframework to true. |
Head branch was pushed to by a user without write access
Triggered by [comment](ghostty-org#12267 (comment)) from @mitchellh. Vouch: @0xDVC Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
|
@0xDVC Looks like |
mitchellh
left a comment
There was a problem hiding this comment.
Sorry for the back and forth on this, I should probably just pick this up myself. Not happy with where this is at currently.
- We should reuse the
emit-xcframeworkand not introduce a new flag (just have it semantically affect lib vt too) - We should change the default to whether we can detect xcode tools or not
- I don't understand why the swift-vt-xcframework Package.swift had to change
@mitchellh The fix was supposed to gate it behind The I'm probably missing something here, but made some new changes. so do have a look |
…ramework on Darwin This fixes a hardcoded build issue on macOS where Zig unconditionally forces xcodebuild -create-xcframework to run during compilation, even when the caller explicitly specifies that they only want the raw standard C objects/headers (-Demit-lib-vt). The Bug: Around line 155 in build.zig, the libghostty-vt xcframework was being packaged unconditionally for Darwin builds. This caused developers (and wrappers like go-libghostty) attempting to natively build the vt library locally using only the minimal macOS Command Line Tools to experience an immediate crash, as xcodebuild -create-xcframework strictly demands a full Xcode application installation. The Fix: Guarded the GhosttyLibVt xcframework creation step with config.emit_xcframework. Because src/build/Config.zig intuitively forces emit_xcframework to default to false whenever emit_lib_vt is invoked, this structurally allows lightweight macOS builds to safely skip the xcodebuild invocation while still correctly compiling the standard .a object library files.
86dbecf to
44a2d87
Compare
mitchellh
left a comment
There was a problem hiding this comment.
That looks right! I rebased and got rid of the libc++ linkage on our Swift example, we don't rely on libc++ anymore.
This fixes a hardcoded build issue on macOS where Zig unconditionally forces xcodebuild -create-xcframework to run during compilation, even when the caller explicitly specifies that they only want the raw standard C objects/headers (-Demit-lib-vt).