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

use vendored_frameworks for Parse.framework, fixes for 0.38 cocoapods #13253

Closed
wants to merge 1 commit into from

Conversation

siuying
Copy link
Contributor

@siuying siuying commented Jul 6, 2015

Fixes the problem missing header in cocoapods 0.38

@segiddins
Copy link
Member

@nlutsenko This look OK to you? 👍

This will fix CocoaPods/CocoaPods#3822

@nlutsenko
Copy link
Contributor

Not sure, but I don't think so.
The tricky part is that we are shipping Static framework and want to surface both static and dynamic linking, for things like Swift projects.

By using this crazy thing - we can link as a framework and as a regular static pod.

@nlutsenko
Copy link
Contributor

Also, latest is 1.7.5.1 (has the -ObjC linker flag forced)

@nlutsenko
Copy link
Contributor

Found another way to fix this, but need a verification.

s.public_header_files = '*.h'
s.source_files = '*.h', 'Empty.m'
s.preserve_paths = 'Parse.framework/Parse'

s.vendored_library = 'libParse.a'
s.prepare_command = 'touch Empty.m && cp Parse.framework/Parse libParse.a && cp Parse.framework/Headers/* .'

@segiddins Does this look sane to you?

@nlutsenko
Copy link
Contributor

Or actually just replacing public_header_files with s.public_header_files = 'Parse.framework/Headers/*.h' seems to work reliably.
I am wondering if glob expansion is just doing something weird...

@segiddins
Copy link
Member

No, in 0.38 we only link Headers in .framework if it's a vendored framework to fix other issues. This hack that you're using is totally unsupported and iirc completely doesn't work in 0.38. The correct answer to support dylib usage is to ship a dynamic binary.

@nlutsenko
Copy link
Contributor

Would any of the above solutions work for this? Shipping dynamic framework is not exactly an option right now... We will get there, but I would love to unbreak it for people even if it's a temporary solution.

@nlutsenko
Copy link
Contributor

Ok, the hack above (cping headers from .framework) seems to actually work, since the headers are no longer in .framework :D
I am going to roll-forward the podspec.

@nlutsenko
Copy link
Contributor

@siuying @dcow Would appreciate if you guys could verify that it works with pod 1.7.5.2

@ArtSabintsev
Copy link
Contributor

👍 Would love to get feedback on this solution as well, as I'm currently going down the same path.

@roland9
Copy link

roland9 commented Jul 31, 2015

any updates - encountering the same issue here :(

@ArtSabintsev
Copy link
Contributor

I originally came to this post attempting to solve this issue for other third-party static libs (not Parse). I was able to get it working by augmenting existing podspecs. Here's a tutorial I wrote about it: https://medium.com/@ArtSabintsev/importing-c-static-libraries-into-a-swift-project-using-cocoapods-a53993c3a2ca

@keith
Copy link
Member

keith commented Dec 23, 2015

Any resolution to this?

@nlutsenko
Copy link
Contributor

@keith Since now we are using completely different way of shipping (since we are open source), as well as podspec is very very different - I don't think this PR is relevant anymore, unless someone explicitly wants to use a 6 months old version of the framework.

@keith
Copy link
Member

keith commented Dec 23, 2015

👍 closing

@keith keith closed this Dec 23, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
7 participants