-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Allow podfile to specify if dependency should be statically linked #7428
Comments
This issue is a precursor to a larger refactor we would like to do in potentially a CocoaPods 2.0 version in which we allow app developers to choose how to pack and link a given pod (of course with some limitations and input from the pod author). I can keep this issue open since we do not have any other issue that closely asks for this, however, I do not anticipate any immediate work on this. An ugly solution is to publish a separate podspec that uses the static framework flag. It's the best I can give you for now. |
Just for reference, this library can be used in the meantime: https://github.com/keith/swift-staticlibs |
An easy but non-standard solution to choosing between static or dynamic linking is adding the following to the Podfile (I've tried and used it with CP 1.4):
We enable the use of frameworks and then make us of the Curious to see what the CocoaPods team think about this. It's probably not their first recommendation, but I'm putting it out here just for the discussion. |
It's a nice hack IMO ;) |
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
Thanks for posting @bpoplauschi! I've spent hours trying to figure this out and your solution worked for me. |
This is what worked best for my project for others still looking at this-
|
Update for CP 1.7+ - I tried @dmac81's solution, but it didn't work (all frameworks were still built as dynamic). What worked for me was pre_install do |installer|
installer.pod_targets.each do |pod|
if $static_framework.include?(pod.name)
def pod.build_as_static_framework?;
true
end
end
end
end This is the same principle as above, just taking into account the deprecation of |
@bpoplauschi's updated solution still didn't work for me (Xcode 11 beta 4 + CP 1.7.5) :( |
We have just upgraded from 1.6.x to 1.7.3 and using the new We are actually seeing the framework getting embedded in the app's This is all using Xcode 10.2.1. Is this expected behavior? It feels like if the framework's code is getting linked into the main binary, the resources should follow suit? As it is right now, it feels like the framework is part dynamically linked, part statically. |
@FarAndHeight @hujunfeng you are probably right. After all, we are hacking around the built in CP features, so it's expected that as some point, things will go south. |
I noticed that there are some duplicated file linker errors that show up when overriding Here is what fixed this for me. Riffing off of @bpoplauschi
|
@bpoplauschi @dmac81 : I am using Cocoapods 1.8.4 and neither of these solutions work. Do you have any pointers? |
What do you mean by "publish a separate podspec". Can you please elaborate? |
Part of this will be available in 1.9 but not on a per-pod basis and rather on on a global basis through |
I managed to change a good percentage of my frameworks from dynamic to static. However, when trying to send the binary do AppStore the following error is displayed: |
I have to change to
|
You can also use a cocoapod plugin like: |
Thanks for adding support for static frameworks in v1.5.0! 🌈
I'd like to switch several of my dependencies to be statically linked, but I'm not sure if it safe for the library authors to make this change for everyone.
Here is a discussion where Keychain-Swift is weighing the pros/cons: evgenyneu/keychain-swift#74
Rather than having the library writer force static or dynamic, can we have the user of the pod choose?
The text was updated successfully, but these errors were encountered: