-
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
[RFC] Expanding use_frameworks!
to allow specifying static (or dynamic) linking
#9099
Comments
LGTM! - just a few nits ... In the second paragraph, I think you mean "pod consumers" instead of "pod authors". From a CocoaPods perspective, the "Since Xcode 9" could be changed to "Since CocoaPods and the introduction of the podspec attribute "static_framework"". |
Looks great 👍 |
There's a |
Yeap will take care of it after vacation. |
Would there be any way to override this setting at a per pod level?
The reason for the dynamic_frameworks list is that certain pods don't work as static frameworks, but it's still nice to get the benefit of static frameworks for the majority. |
@cltnschlosser yes! there is a proposal for this here https://docs.google.com/document/d/1lr2mHkwhNha5_0Wfa_pYL51MAxoro0LBxx_DUzuSu0Y/edit but I wanted to flesh out this one separately since its a much easier change. |
@dnkoutso I . thought you were also proposing allowing specifying packaging on a per-pod basis? |
@segiddins I decided to split it into two. See #9099 (comment). This change is much easier to implement and more certain. Even if we decided to do |
Yeah this seems like a simple win and a natural 1st step towards the per-pod solution |
Expanding
use_frameworks!
DSL (specifying linkage style)use_frameworks!
DSL to accept linkage style. Core#581, Integrateuse_frameworks!
linkage DSL. #9119Introduction
CocoaPods today provides little space for pod consumers to customize how they want their pods to be linked. As of today, pod consumers are only able to customize different packaging (static library vs framework) via the
use_frameworks!
DSL. The linking style happens to be a side-effect of that decision without giving pod consumers a proper way to configure it.This RFC aims to expand the
use_frameworks!
DSL in order to give pod consumers a little bit more control and allow them to specify the link style they want if they decide to integrate their pods using frameworks.Motivation
Leveraging the
.framework
bundle structure has proven to be very useful. Using frameworks was also a hard requirement in the earlier days of Swift.Here's the definition of a framework from Apple:
Up until recently, a
.framework
mostly contained a dynamic shared library which was loaded at runtime when the application launched. However, this could cause issues when the number of dynamic libraries grows high enough because the app would take longer to boot. In some extreme cases, the app would be killed off by the system if it took too long to load all dynamically shared libraries.Since CocoaPods introduced the
static_framework
DSL, only pod authors could leverage the.framework
structure but instead force static linkage. On the other hand, pod consumers still have no way of specifying that they want to use.framework
packaging but instead statically link their pods into their app executable.Giving this option to pod consumers would give them more control and allow them to leverage both the
.framework
structure but also avoid some of the aforementioned issues.Proposed solution
Extend the existing
use_frameworks!
DSL in order to allow pod consumers to specify how they want linking to happen via a hash.Detailed design
Core gem changes
Move
BuildType
class into core gemThe recently introduced
BuildType
class encapsulates all of packaging and linking concepts into one very simple and well tested class. This can be leveraged as part of this work in order for it to be used as an easy to understand model for storing all information related to a target definition's desired build type.Thus, as part of this proposal, the
BuildType
class and its specs will move over to the CocoaPods/Core gem.Expanding
use_frameworks!
The current
TargetDefinition
use_frameworks!
method is defined as such:It stores the given
flag
as aBoolean
in the target definition's hash.The re-defined method will accept both a
Boolean
and aHash
and instead serialize an instance ofBuildType
class into the target definition's internal hash and will contain both the packaging and linkage information.As you can see, the
'uses_frameworks'
key stored in the target definition's hash will not change in order to maintain backwards compatibility for existingPodfile
files that may have been serialized (for example, intoyaml
).Furthermore, the default value of the
option
parameter will remaintrue
also in order to maintain backwards compatibility with all of the existing configurations that currently specifyuse_frameworks!
in theirPodfile
.An additional method will be introduced in the
TargetDefinition
class that returns the (desired) build type it requires:Finally, the
TargetDefinition#uses_frameworks?
method will also need to be updated to work with the new hash that is now being stored:With the above changes the following examples are now possible:
This concludes the changes required for the Core gem.
CocoaPods gem changes
As mentioned, most of the work for supporting the notion of different packaging or linking types has already been completed through the aforementioned
BuildType
class that was introduced in the 1.7 release. This also includes variant support and CocoaPods will automatically split a pod that is consumed across targets with different build types for both packaging and linking.Update
BuildType
referencesSince the
BuildType
class will be moved as part of this proposal, all references must be updated in the CocoaPods gem. This should be straightforward find/replace.Remove
host_requires_frameworks
boolean flagThe existing
host_requires_frameworks
boolean flag found inTarget
is no longer needed and it is redundant given that the initializer requires aBuildType
instance to be passed in.As part of this proposal, the
Target
class and it's subclasses will need to be updated to removehost_requires_frameworks
boolean flag and instead update all callers to rely on theBuildType
attribute.Additionally, all initializers will be updated to require a
BuildType
as it currently appears to be optional and can accept anil
value which should never be the case.Update
analyzer
The
analyzer
will need to be updated in order to take into consideration the (desired)BuildType
specified in theTargetDefinition
when constructingPodTarget
instances.A new method will be added that calculates the
BuildType
to use:The above method will be used by the
analyzer
when determining theBuildType
to use for aPodTarget
instance.Backwards compatibility
Most of the concerns around backwards compatibility have already been covered in the 'Detailed Design' section especially regarding the serialization of the
Podfile
and ensuring that existing setups that useuse_frameworks!
continue to function after this proposal is implemented.This proposal has no effect on
podspec
files and therefore it is considered a low-risk change.Alternatives considered
An alternative was to introduce a new
use_static_frameworks!
DSL that would have the same effect. However, this was avoided due to the proliferation of DSL options in CocoaPods and would require additional linting in order to ensure it is mutually exclusive with theuse_frameworks!
option.Another alternative as always is to do nothing in which case CocoaPods will remain very limited in its configuration options regarding linking and packaging during integration.
The text was updated successfully, but these errors were encountered: