Do not warn for missing arch if $ONLY_ACTIVE_ARCH is set to NO.
#10114
Conversation
dnkoutso
force-pushed
the
only_active_arch_no_warning
branch
from
fd0b82e
to
6f7d8ff
Compare
dnkoutso
force-pushed
the
only_active_arch_no_warning
branch
from
6f7d8ff
to
bcc5fa6
Compare
dnkoutso
force-pushed
the
only_active_arch_no_warning
branch
from
bcc5fa6
to
d8583f9
Compare
| @@ -33,7 +33,7 @@ module ScriptPhaseConstants | |||
| intersected_archs="$(echo ${ARCHS[@]} ${binary_archs[@]} | tr ' ' '\\n' | sort | uniq -d)" | |||
| # If there are no archs supported by this binary then warn the user | |||
| if [[ -z "$intersected_archs" ]]; then | |||
| if [[ "$warn_missing_arch" == "true" ]]; then | |||
| if [[ "$warn_missing_arch" == "true" ]] && [[ "$ONLY_ACTIVE_ARCH" == "NO" ]]; then | |||
There was a problem hiding this comment.
Replying to @dnkoutso's #10076 (comment).
I confirm that the warning is indeed gone for debug builds, but it is still present for release builds. I see the following warning when I archive in Xcode 12 (stable) for "Any iOS Device (arm64)":
warning: [CP] Vendored binary '/Users/radazzouz/Library/Developer/Xcode/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/Minimal/IntermediateBuildFilesPath/Pods.build/Release-iphoneos/PSPDFKit.build/DerivedSources/PSPDFKitUI.framework.ios-x86_64-maccatalyst.dSYM/Contents/Resources/DWARF/PSPDFKitUI' contains architectures (x86_64) none of which match the current build architectures (arm64).I don't think we should see this warning when archiving for iOS because it refers to the Mac Catalyst architecture.
I suspect that this happens because CocoaPods copies all the dSYMs (including the simulator and Mac Catalyst) into the iOS archive.
BTW, the same thing happens (warnings about the iOS dSYMs) when I archive for Mac Catalyst.
I hope that this helps!
There was a problem hiding this comment.
@radazzouz hmmm for release ONLY_ACTIVE_ARCH is set to YES therefore cocoapods should warn that you are missing an architecture for the archs that you are building for right?
How can this be avoided in this case?
There was a problem hiding this comment.
Yeah. That's strange. Could it be because $intersected_archs (from a few lines above) includes all the architectures (including architecture that we we're not building/archiving for)? If that's the case, then I think that $intersected_archs should not include the Mac Catalyst architecture when archiving for iOS and vice-versa.
There was a problem hiding this comment.
hmmm I think I see the issue let me try a few things.
There was a problem hiding this comment.
CocoaPods will install all dSYMs in the shell script
install_dsym "/Users/dimitris/Downloads/Minimal-CocoaPods/Pods/PSPDFKit/PSPDFKit.dSYMs/PSPDFKit.framework.ios-x86_64-maccatalyst.dSYM"
install_dsym "/Users/dimitris/Downloads/Minimal-CocoaPods/Pods/PSPDFKit/PSPDFKit.dSYMs/PSPDFKit.framework.ios-arm64.dSYM"
install_dsym "/Users/dimitris/Downloads/Minimal-CocoaPods/Pods/PSPDFKit/PSPDFKit.dSYMs/PSPDFKit.framework.ios-arm64_x86_64-simulator.dSYM"
install_dsym "/Users/dimitris/Downloads/Minimal-CocoaPods/Pods/PSPDFKit/PSPDFKitUI.dSYMs/PSPDFKitUI.framework.ios-x86_64-maccatalyst.dSYM"
install_dsym "/Users/dimitris/Downloads/Minimal-CocoaPods/Pods/PSPDFKit/PSPDFKitUI.dSYMs/PSPDFKitUI.framework.ios-arm64.dSYM"
install_dsym "/Users/dimitris/Downloads/Minimal-CocoaPods/Pods/PSPDFKit/PSPDFKitUI.dSYMs/PSPDFKitUI.framework.ios-arm64_x86_64-simulator.dSYM"
We either need to update this logic to be backed by ARCHS or update the warning to handle this case.
There was a problem hiding this comment.
Considering alternative path again around the warning logic...
There was a problem hiding this comment.
@radazzouz do xcframeworks contain all dSYMs always?
Yes. We bundle a dSYM for each platform (iOS device, simulator, and Mac Catalyst). We bundle the dSYMs for our XCFrameworks in the ${framework_name}.dSYMs directory next to the XCFramework itself, as recommended by CocoaPods.
There was a problem hiding this comment.
@radazzouz I stumbled onto your PR while doing some testing regarding xcframework debug symbols with Xcode 12 and wanted to bring the work I'm doing to your attention (#10111 and PR #10122).
In short, Xcode 12 now supports an Apple-recommended approach for where debug symbols are placed with XCFrameworks. When using the new structure, manually dragged in XCFrameworks will automatically have their relevant debug symbols included in app archives, so I've been working a PR to ensure that CocoaPods also supports including symbols that are placed based on the new structure.
@dnkoutso your question of "Do xcframeworks always include those and are they named always by architecture? Is that standard in the xcframework structure?" relates to the work I'm doing as well... there's only an official placement for where they should go as of Xcode 12, but we also have the approach @radazzouz is describing which was the CocoaPods recommended placement when XCFrameworks were originally introduced.
I believe that the warning that is being hit here is only relevant in the context of the Xcode 11 style symbols where the MyLib-copy-dsyms.sh script is used and is copying all dSYMs. This script is not generated when using Xcode 12 style XCFramework debug symbols.
There was a problem hiding this comment.
Thank you so much for the heads up @johntmcintosh! ❤️ I’ll take #10122 for a spin some time next week and I’ll make sure that the new PSPDFKit XCFrameworks for CocoaPods will be updated after the PR lands.
There was a problem hiding this comment.
Catching up - I don't think explicitly removing the warning in this case is the right way to go. As @radazzouz suggested we should catch this earlier and not install those dSYMS at all unless they are appropriate for the current architecture
closes #10076
integration specs: CocoaPods/cocoapods-integration-specs#299