-
-
Notifications
You must be signed in to change notification settings - Fork 21.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[iOS] Fix dotnet export. #84945
[iOS] Fix dotnet export. #84945
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -194,7 +194,7 @@ private void _ExportBeginImpl(string[] features, bool isDebug, string path, long | |
BundleOutputs = false, | ||
IncludeDebugSymbols = publishConfig.IncludeDebugSymbols, | ||
RidOS = OS.DotNetOS.iOSSimulator, | ||
UseTempDir = true, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm testing this right now, and the problem is not the temp dir output, the problem is that the xcframework command should not be including the library argument that's pointing to the temp dir. The simulator dylib should be already lipo'd into the non-simulator dylib, so there should be no references to the simulator dylib anymore. This might look like it fixes things, but it's not the correct fix here. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
This is impossible, simulator lib can't be lipoed with non simulator lib since both contain arm64 code, that's the only season xcframeworks exist in a first place (merging libs for the different platform but the same architecture). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry, I mispoke, the x64 and arm64 simulator dylibs are lipo'd together, and the lipo result is what we want, not the separate dylibs. This is not where the fix should be, the fix is where the lipo happens for iOS, where the output paths are adjusted for creating the framework. This is the correct fix for the problem where the xcframework fails to be created properly: https://github.com/godotengine/godot/compare/master...shana:godot:fix-ios-dotnet-export?diff=unified Could you add a comment on this line that this is a temporary fix with a link to this PR, so we don't forget to fix it up properly? |
||
UseTempDir = false, | ||
}); | ||
} | ||
|
||
|
@@ -361,7 +361,7 @@ private void _ExportBeginImpl(string[] features, bool isDebug, string path, long | |
} | ||
|
||
var xcFrameworkPath = Path.Combine(GodotSharpDirs.ProjectBaseOutputPath, publishConfig.BuildConfig, | ||
$"{GodotSharpDirs.ProjectAssemblyName}.xcframework"); | ||
$"{GodotSharpDirs.ProjectAssemblyName}_aot.xcframework"); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For the reference, this is the only changed line in the last push. Added to fix name conflict (#82729 (review)) and should not have any effect on the rest of code. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I just ran into the same export problem with the naming conflict, it's an Xcode 15 thing, apparently. This fixes it 👍 |
||
if (!BuildManager.GenerateXCFrameworkBlocking(outputPaths, | ||
Path.Combine(GodotSharpDirs.ProjectBaseOutputPath, publishConfig.BuildConfig, xcFrameworkPath))) | ||
{ | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're not using the
AotBuilder
class, it's a remnant from Godot 3.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably remove unused classes (not in this PR), they can always be brought back from the Git history if needed in the future.