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
Add Xcode 12 compatible support for debug symbols in XCFrameworks #10111
Comments
I did not implement XCFrameworks so I forget...do we manualloy copy those and the issue here is that we are missing some? |
Thanks for the great report, yes a sample app is always helpful. |
@dnkoutso correct, the symbols are manually copied and it looks like the relevant scripts (described below) are only looking inside of each architecture's Background To add some more background, my understanding from reading up on some of the original work (I think from the PSPDFKit team) and from @steipete's Twitter is that with Xcode 11 Apple had not provided much guidance on how debug symbols should be handled with XCFrameworks. As a result, I think that the current approach of placing them inside the Proposal Going forward, I assume that the ideal case may be for CocoaPods to support pulling in the debug symbols from both locations (sibling or child of the Implementation On the implementation side, from the tracing I've done so far I'm seeing that after running
The Continuing to trace what I think is happening... there's also a generated I think then that what would need to happen to get this working is:
Tomorrow, I can put together a couple of small XCFrameworks as local pods that are setup with a sample Podfile and project so we can have one example that covers both use-cases. |
This is great. We can even add an example project for this to ensure it fails without any changes and then starts working with your changes. |
accidental close, sorry! |
Great write up! Your proposed solution sounds great, especially considering we'd like to continue the existing solution for Xcode 11 at least until Xcode 13 / end of 2021. I'd be happy to review PRs towards this, but I likely won't be working on this myself in the near future |
@johntmcintosh feel free to try! We can help you land this. |
Thanks @dnkoutso -- I have a standalone sample project setup now with two test xcframeworks (one of each style) and a script to compile the wrapper app and evaluate whether the expected symbols are included or not. I think this gets me to a good point now for manually editing the generated scripts until they're doing what I want, and then work backwards into the tool to get CocoaPods to generate the expected scripts on a I've run into some trouble getting Rainforest setup and could probably use some pointers if you have any ideas: CocoaPods/Rainforest#88. |
@johntmcintosh no need to use Rainforest, just fork this repo normally and cocoapods-integration specs repo and make a PR from that. |
@dnkoutso good news -- I've identified a change in the generated scripts (smaller than I originally expected!) that appears to get this working in my example, so now I'm starting to look more seriously into how to test some things out building into the tool locally. I've gotten setup where I can A couple of questions regarding project conventions and such:
Thanks! |
When sitting down this morning to get back into this, it hit me that that the distinction that I was looking to test (differing input library structures) wasn't really a valid use-case for the integration tests, since those are testing the result of a I've now updated all of the relevant test cases to pass and reflect the change that I'm proposing. The missing piece still may be adding a new test or example that ensures that the core change of the generated script is actually the right change to be making. I think I'm at a reasonable point to put up a PR though, and we can sort out any additional test cases like that in the PR. |
…mbols placed as siblings of the .framework inside each arhictecture's directory
… debug symbols placed as siblings of the .framework inside each architecture's directory
… debug symbols placed as siblings of the .framework inside each architecture's directory
The examples are built in CI and may be a more appropriate place to test these integrations. We don't currently have separation of Xcode versions in those but we could. The place that handles building the examples is here: Lines 282 to 285 in a3632cc
Definitely not a blocker for landing these PRs though, we can make incremental progress here |
Thanks @amorde! I actually found those today a little while after getting the PRs up. Most of the current examples there do a standard build on the target and I think that the test passing/failing just depends on the target successfully compiling, is that correct? For this use-case I think that the evaluation we'd want to do of debug symbols requires an archive build to be done. (At least in my testing I've been doing an archive since the symbols are placed at the root directory of the final archive. It may be that they are available at a different path for regular builds and if so a regular build might be able to be used more simply.) Assuming that understanding is correct, I can look into creating an aggregate target in the Vendored XCFramework example and then have a run script that does an archive and exits with a failing return code if the expected symbols are not present in the built archive. I'm assuming that we would need to do something like that so that the general loop that runs xcodebuild on all schemes would still support this specific test. Let me know if you have any other/better ideas on how would be best to go about setting that up. |
…code12 #10111 - Update XCFramework installation to support Xcode 12 debug symbols
@johntmcintosh should we close this now that the PR landed? I am planning to ship 1.10 very soon. |
@dnkoutso I had been leaving it open while the PR that adds the example test was still open, but functionally this issue is resolved now with the original PR merged. Feel free to close it out, or I will if it's still open when the example test case is merged. |
@johntmcintosh thanks a lot, will close and merge your examples PR. |
* 1-10-stable: [CHANGELOG] Add empty Master section Release 1.10.0 Bump Xcodeproj to 1.19 Update project config to be more compatible for building with Xcode 11.3.1 Update BananaLib build script to output archives in the gitignored build/DerivedData directory Update CoconutLib build script to output archives in the gitignored build/DerivedData directory Pull archive and validate script out as its own file Build the BananaLib XCFramework, include it in the example project, and update the ArchiveAndValidate script to inspect the results Create a BananaLib that will be used to build an xcframework using the Xcode 11 style of debug symbol placement Add ArchiveAndValidate aggregate target that ensures the expected dSYMs and BCSymbolMaps are present in the root of the archive Build the xcframework and install the pod in the example project Create a sample project and build script for generating an xcframework with Xcode 12 style debug symbols Add example scheme that was missing Update integration-specs submodule pointer #10111 - Update XCFramework installation to support Xcode 12 debug symbols placed as siblings of the .framework inside each architecture's directory
* 1-10-stable: [CHANGELOG] Add empty Master section Release 1.10.0 Bump Xcodeproj to 1.19 Update project config to be more compatible for building with Xcode 11.3.1 Update BananaLib build script to output archives in the gitignored build/DerivedData directory Update CoconutLib build script to output archives in the gitignored build/DerivedData directory Pull archive and validate script out as its own file Build the BananaLib XCFramework, include it in the example project, and update the ArchiveAndValidate script to inspect the results Create a BananaLib that will be used to build an xcframework using the Xcode 11 style of debug symbol placement Add ArchiveAndValidate aggregate target that ensures the expected dSYMs and BCSymbolMaps are present in the root of the archive Build the xcframework and install the pod in the example project Create a sample project and build script for generating an xcframework with Xcode 12 style debug symbols Add example scheme that was missing Update integration-specs submodule pointer #10111 - Update XCFramework installation to support Xcode 12 debug symbols placed as siblings of the .framework inside each architecture's directory
Report
With Xcode 11, there was no automated mechanism for Xcode to embed debug symbols (dSYMs and BCSymbolMaps) that were embedded in an XCFramework into the built product's archive. As a result, CocoaPods' support for XCFrameworks included automatically extracting debug symbols from each architecture's framework directory, and including them into the built app. The expectation was that the XCFramework would be structured like this:
EDIT (Oct 7): Originally I had described that the dSYMs were placing as siblings of the BCSymbolMaps in the Xcode 11 style, but after some additional testing, I realized that the Xcode 11 style that CocoaPods was expecting was for the dSYMs to be placed in a .dSYMs directory as a top level sibling of the .xcframework.
This was great!
Now, Xcode 12 has added support to
xcodebuild -create-xcframework
for passing a-debug-symbols
argument. When creating an XCFramework this way with Xcode 12, the resulting directory structure does not match what we had presumed when initially building support for Xcode 11:The debug symbols are placed as siblings of each architecture's
.framework
rather than as children of it.As a result, when integrating through CocoaPods, the debug symbols from this type of XCFramework are not being included in the final product archive.
What did you expect to happen?
XCFrameworks that are compiled with Xcode 12 to include debug symbols should automatically support those debug symbols being included in the built app when integrating the XCFramework through CocoaPods.
What happened instead?
XCFrameworks that are compiled with Xcode 12 to include debug symbols automatically support debug symbol inclusion in the built app when manually added to the parent project, but not when integrated through CocoaPods.
CocoaPods Environment
Stack
Project that demonstrates the issue
I do not have an accessible sample project right now, but wanted to go ahead and create the ticket for visibility as it would be fantastic if this support were able to be added as part of the upcoming 1.10.0 release that already includes several other XCFramework improvements.
The text was updated successfully, but these errors were encountered: