grab / cocoapods-binary-cache

MIT License
477 stars 69 forks source link

Disable absolute paths for .dSYMs #99

Closed shahzadmajeed closed 2 years ago

shahzadmajeed commented 2 years ago

Checklist

Issue Description

Command executed

Binaries were built with `bundle exec pod binary prebuild --all --verbose`
Now debugging fails in main project. We see following error when we run `po`, `p` lldb commands in Xcode

```
error: virtual filesystem overlay file '/Users/abc/MyiOSProject/build/Pods.build/Release-iphonesimulator/AWSMobileClient.build/all-product-headers.yaml' not found
```

What went wrong?

We are noticing debugging issues in our main project. On investigation we found the issue is this https://steipete.com/posts/couldnt-irgen-expression/ but I am wondering how to add `-no-serialize-debugging-options` flag for `xcodebuild` command.

Environment

Plugin version

0.1.14

Installed CocoaPods plugins

bundle exec pod plugins installed

Installed CocoaPods Plugins:
    - cocoapods-binary-cache : 0.1.14 (pre_install and post_install hooks)
    - cocoapods-deintegrate  : 1.0.5
    - cocoapods-plugins      : 1.0.0
    - cocoapods-search       : 1.0.1
    - cocoapods-trunk        : 1.6.0
    - cocoapods-try          : 1.2.0
shahzadmajeed commented 2 years ago

It seems there is no way to include arguments for create-xcframework command but following did the trick for the issue I was facing.

build_args: {
    :default => ["SWIFT_SERIALIZE_DEBUGGING_OPTIONS='NO'"]
}
trinhngocthuyen commented 2 years ago

I think the above configuration (using build_args) seems like an appropriate workaround for the issue. Alternatively, you can update the corresponding setting in post_install hooks.

shahzadmajeed commented 2 years ago

Yes, build_args worked for now. Although there is no way to include arguments for xcframeworks command at this point.

Just a clarifying question on post_install hooks.. Doesn't post_install hook phase happen after the binaries are built?

trinhngocthuyen commented 2 years ago

Let me quickly explain how it works in this case.

1/ When prebuilding frameworks, the plugin creates a dedicated installer to build the frameworks. This installer has the Pods project in _Prebuild/Pods.xcodeproj (let's call this the prebuild Pods project), not Pods/Pods.xcodeproj (let's call this the default Pods project). You can find this prebuild Pods project in the xcodebuild command printed to the console when prebuilding frameworks.

2/ The prebuild Pods project has (almost) identical build settings with the default Pods project b/c it goes through a full installation like in the default Pods project. The hooks (pe_install & post_install) are triggered during its installation.

3/ Only after the installation of the prebuild Pods project finishes do we prebuild the frameworks.


Following is the order of the steps happening in a prebuild scenario

- validate cache (hit & missed)
- prebuild missed cache
    - create prebuild installer (sandbox: _Prebuild)
    - run prebuild installer (to generate _Prebuild/Pods.xcodeproj)
        - pre_install & post_install hooks are called as usual (but for _Prebuild/Pods.xcodeproj)
    - build frameworks (against _Prebuild/Pods.xcodeproj)
- integrate back to Pods/Pods.xcodeproj

In short, the plugin guarantees that what customized settings you have for the project will properly take effect when prebuilding frameworks.

Hope the explanation clears your doubt.

shahzadmajeed commented 2 years ago

@trinhngocthuyen thank you for explaining pre-building frameworks process. That makes sense and I, now, understand the purpose of _Prebuild/Pods.xcodeproj.

The reason I got the perception that post_install might happen after building the frameworks is because that was the first thing I tried when I was trying to add SWIFT_SERIALIZE_DEBUGGING_OPTIONS but I couldn't see it as part of xcodebuild command. I must have done something wrong there.

Again, thank you for such a detailed response on the process.