Building static frameworks

[robinkunde]

Hey there, I really like this tool. There's a use case I'm trying to figure out.

The pod file I use doesn't specify use_frameworks!, so all pods are built as static frameworks by default. PodBuilder doesn't seem to support that yet. I tried specifying "static_framework": true in spec_overrides, but that only works for private pods. If I try it with Alamofire, both in my own podfile and in PodBuilder's example project, even though pod_builder info reports "is_static": true afterward, the framework is still dynamic. Moreover, it seems to stop the static framework's resource bundles from being built.

I realize these are probably interconnected issues, and I'm happy to help fix it, but right now I'm not sure where to start.

[tcamin]

PodBuilder does not support static libraries (the one produced by not using use_frameworks!) because this is basically no longer needed. Static frameworks have all the benefits of static libraries + allowing to embed headers and additional resources in a single package (the .framework folder).

If pod_build info reports that it is statically compiled I'm expecting it should be the case 😄.

What is the output of file Alamofire.framework/Alamofire? If you see ar archive somewhere in the output then the framework is indeed prebuilt statically. Additionally static frameworks do not have the Info.plist manifest under Alamofire.framework.

spec_overrides are expected to work not only for private pods but also for public ones.

That said there is one big caveat: There is an issue with the latest version of CocoaPods and resources/bundles embedded in static frameworks which I reported here: https://github.com/CocoaPods/Rome/issues/81. Due to this issue we're sticking with CocoaPods 1.6.2 in our project (with no major issues of not being on the latest release). This might be/not be a viable workaround, but unfortunately I did not have the time to investigate the issue with CocoaPods further.

[robinkunde]

Sorry for the confusion. Like I said, I am trying to pre-build static frameworks. I mentioned omitting use_frameworks because it's an easy way to build all pods statically without having to fork them and editing each podspec. What you're saying makes sense though and I guess it doesn't apply here. It would be cool to be able to turn on static_framework for all pods at once without having to override each individually.

That said, something's causing the override option to be ignored for some pods. I don't think it's even reading the option for Alamofire, because it did not complain when I specified "static_framework": "true" instead of "static_framework": true.

$ file Frameworks/Rome/Alamofire.framework/Alamofire
Frameworks/Rome/Alamofire.framework/Alamofire: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64]
Frameworks/Rome/Alamofire.framework/Alamofire (for architecture x86_64):    Mach-O 64-bit dynamically linked shared library x86_64
Frameworks/Rome/Alamofire.framework/Alamofire (for architecture arm64): Mach-O 64-bit dynamically linked shared library arm64

Edit: Well, it must be reading it, because it shows is_static in the output of the info command, but it's not applying it to the modified podspec it seems.

[tcamin]

There was indeed a problem 🙄. I created a branch, feature/static_override_example, which shows that now Alamofire can be rebuilt statically by adding the spec override. To test it install the pod-build-beta.gem under the build folder (or alternatively you can build it yourself).

Caveat: the fix involves a CocoaPod's method replacement which should work even with the latest version of CocoaPods, although I did test it only with the 1.6.2.

[robinkunde]

Thanks, I'll check it out.

[tcamin]

I merged the changes to master, you can test it out installing the latest version.

On Sun, 2 Feb 2020 at 15:47, Robin Kunde notifications@github.com wrote:

Thanks, I'll check it out.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Subito-it/PodBuilder/issues/6?email_source=notifications&email_token=AAGVUENRTMMJFRQCM5ZXQTTRA3MI3A5CNFSM4KM6D2V2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKRYPWA#issuecomment-581142488, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGVUEM46AQTUXV3XIJIAMTRA3MI3ANCNFSM4KM6D2VQ .

[opfeffer]

hey @tcamin

thanks for creating this tool-- it looks promising and I'm experimenting with it to see if I could incorporate it into some of my projects:

I have a bunch of statically-linked frameworks that contain resource bundles... I saw your open issue https://github.com/CocoaPods/Rome/issues/81, cocoapods-binary has a similar issue open (see https://github.com/leavez/cocoapods-binary/issues/50).

I'm curious, from what I can tell, the change in CocoaPods 1.7+ is purely about the change in directory of the resource bundle (outside of the created .framework as opposed to inside). Is that correct? If so, as long as CP Copy Resources script knows the right path, this shouldn't really be a show stopper for tools like cocoapods-binary or PodBuilder, right?

I guess what I'm asking---- given the lack of traction/responses on the rome and cocoapods-binary ticket, are there other ways to solve this issue?

Sorry for hijacking this ticket, appreciate any insight you may have! Thanks

[tcamin]

I'm curious, from what I can tell, the change in CocoaPods 1.7+ is purely about the change in directory of the resource bundle (outside of the created .framework as opposed to inside). Is that correct? If so, as long as CP Copy Resources script knows the right path, this shouldn't really be a show stopper for tools like cocoapods-binary or PodBuilder, right?

I had no chance to investigate this however I can imagine that the "new" behaviour might simplify things CocoaPods side: there will be a flat folder containing all resources (potentially coming from different frameworks) that will be copied to the main app instead of having to extract them from each .framework separately.

So far we did not have any issue sticking with CocoaPods 1.6.2 however I understand the need to use the latest version. As soon as I have some time I will try to take a look and see if there's a way around this.

I guess what I'm asking---- given the lack of traction/responses on the rome and cocoapods-binary ticket, are there other ways to solve this issue?

Use CocoaPods 1.6.2 at least for that project? Are there any features that require an updated version?

Sorry for hijacking this ticket, appreciate any insight you may have! Thanks

No problem! 👍🏻

[opfeffer]

Thanks for your quick feedback--- started using CDN support for the master repo introduced in 1.7 (and stabilized in 1.8). So going back to 1.6, unfortunately, isn't really an option at this time..

[tcamin]

I just released version 1.8.2 which monkey patches CocoaPods 1.8 and 1.9 fixing the resources not being copied to the .framework.