Skip to content
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 support for the dSYM for a prebuilt binary. #1698

Open
alloy opened this issue Dec 19, 2013 · 22 comments
Open

Add support for the dSYM for a prebuilt binary. #1698

alloy opened this issue Dec 19, 2013 · 22 comments
Labels
d2:moderate A moderately-difficult ticket that may require a bit of knowledge about the codebase t1:enhancement Enhancements that have not been picked up yet. Please comment if you plan to work on it

Comments

@alloy
Copy link
Member

alloy commented Dec 19, 2013

When a prebuilt binary has been stripped of its debug symbols, adding this will still allow for a better debugging experience during development.

From #1696:

LLDB supports remapping of dSYM source paths via embedded UUID property lists: http://lldb.llvm.org/symbols.html

@alloy
Copy link
Member Author

alloy commented Dec 19, 2013

Regarding how to specify this in the spec, I’m thinking we could do something like:

s.vendored_library = { :name => 'PLCrashReporter', :dSYM => 'PLCrashReporter.dSYM' }

And possibly default to NAME.dSYM if it exists? In which case just s.vendored_library = 'PLCrashReporter' would work as well.

/cc @irrationalfab

@fabiopelosin
Copy link
Member

The default option sounds great!

@CocoaPodsBot
Copy link

Issue has been confirmed by @joelparsons

@alloy alloy assigned CocoaPodsBot and unassigned CocoaPodsBot Mar 29, 2014
@CocoaPodsBot
Copy link

Issue has been confirmed by @davelyon

@alloy alloy assigned CocoaPodsBot and unassigned CocoaPodsBot Mar 29, 2014
@segiddins segiddins added t1:enhancement Enhancements that have not been picked up yet. Please comment if you plan to work on it d3:hard An issue that is difficult to solve and may require significant changes and removed t3:discussion These are issues that can be non-issues, and encompass best practices, or plans for the future. labels Sep 15, 2014
@segiddins
Copy link
Member

Will this still be necessary given that iOS now supports frameworks?

@kylef
Copy link
Contributor

kylef commented Sep 26, 2015

@segiddins Yes, I think a framework should behave the same way.

s.vendored_framework = { :name => 'Stencil.framework', :dSYM => 'Stencil.framework.dSYM' }
├── Stencil.framework
│   ├── Headers -> Versions/Current/Headers
│   ├── Modules -> Versions/Current/Modules
│   ├── Resources -> Versions/Current/Resources
│   ├── Stencil -> Versions/Current/Stencil
│   └── Versions
│       ├── A
│       │   ├── Headers
│       │   │   ├── Stencil-Swift.h
│       │   │   └── Stencil.h
│       │   ├── Modules
│       │   │   ├── Stencil.swiftmodule
│       │   │   │   ├── x86_64.swiftdoc
│       │   │   │   └── x86_64.swiftmodule
│       │   │   └── module.modulemap
│       │   ├── Resources
│       │   │   └── Info.plist
│       │   └── Stencil
│       └── Current -> A
└── Stencil.framework.dSYM
    └── Contents
        ├── Info.plist
        └── Resources
            └── DWARF
                └── Stencil

15 directories, 10 files

@segiddins
Copy link
Member

@kylef is there no place in the .framework itself to put a dSYM?

@kylef
Copy link
Contributor

kylef commented Sep 26, 2015

I'm not sure, but this is how Xcode generates it, separately.

@ulhas
Copy link

ulhas commented Jan 8, 2016

+1 for this issue. Would be awesome for CocoaPods to have support for dsyms for a framework.

@segiddins
Copy link
Member

@ulhas the quickest way to get a feature like this into CocoaPods would be to submit a PR for it 🚀

@oleksii-demedetskyi
Copy link

Basically dSYM and .bcsymbolmap support is a copy 3 files to Products directory. Is there any hook where this files can be specified? Like resources. Script example

@dnkoutso
Copy link
Contributor

dnkoutso commented Mar 7, 2017

I know this is an old issue but we just hit this case and worth adding support. The proposed API seems good.

@piotrtobolski
Copy link

Can this be closed? #6536 was merged

I hope this will be released soon 👍

@dnkoutso
Copy link
Contributor

Not sure if it should. The original issue was discussing adding a DSL option. Let's wait and see how the current implementation that assumes the same name goes.

@falcon283
Copy link

I'm really looking forward to have this feature.
I'm planning to use vendored SDK for the project I'm working on, and the ability to just link them instead of instead of building them every time sounds awesome but I really need to wrap up all the dSYM into the final application dSYM in order to easily track down crashes in my App and frameworks too.

Is this intended for this purpose? Is there any planned release date for this?

@dnkoutso
Copy link
Contributor

If you use bundler you can lock CocoaPods to a specific SHA.

This should ship this week or next with 1.3.0.beta.1.

@c5f
Copy link

c5f commented Jul 24, 2017

@dnkoutso is there usage documentation for #6536 ? maybe an example .podspec?

@dnkoutso
Copy link
Contributor

No, there is no DSL added for it. If you attach a dSYM next to the .framework then it will automatically be detected and processed by CocoaPods.

@dnkoutso
Copy link
Contributor

dnkoutso commented Jan 29, 2018

For anyone who wants to follow progress here, CocoaPods now supports vendored dSYM support but only if the name of the dSYM matches that of the vendored framework.

This issue will remain open to extend the DSL to allow pod authors to specify a specific/different name of a dSYM file.

@mknippen
Copy link

Having this issue now. CocoaPods does appear to copy over the DSYM files when following this plan, but it's not moving to Apple when using Bitcode. Can anyone confirm?

@dnkoutso dnkoutso added d2:moderate A moderately-difficult ticket that may require a bit of knowledge about the codebase and removed d3:hard An issue that is difficult to solve and may require significant changes s2:confirmed Issues that have been confirmed by a CocoaPods contributor labels May 16, 2018
@rostopira
Copy link

@dnkoutso could you please make it clear, how it should match?
If I have WebRTC.framework, should I place a WebRTC.dSYM or WebRTC.framework.dSYM in same folder?
Thaks

@dnkoutso
Copy link
Contributor

dnkoutso commented Aug 7, 2021

@rostopira must be WebRTC.framework.dSYM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
d2:moderate A moderately-difficult ticket that may require a bit of knowledge about the codebase t1:enhancement Enhancements that have not been picked up yet. Please comment if you plan to work on it
Projects
None yet
Development

No branches or pull requests