search

google / EarlGrey

:tea: iOS UI Automation Test Framework
http://google.github.io/EarlGrey/
Apache License 2.0
5.62k stars 742 forks source link

EarlGrey 2.0 | Publish as framework #820

Open bootstraponline opened 5 years ago

bootstraponline commented 5 years ago

Because static libraries add additional problems that must be solved: like how to expose the headers for the projects that use the dependency. Static frameworks support this nicely (it's basically a static library that's bundled with the headers), so there's no reason to support static libraries by themselves.

https://github.com/Carthage/Carthage/issues/2685#issuecomment-455258498

Based on feedback from the Carthage team, I recommend that EarlGrey 2 move the static libs to static frameworks. Otherwise it's not possible for EarlGrey 2 to be properly consumed by Carthage.

LeoNatan commented 5 years ago

Any reason not to use a dynamic framework in all cases?

bootstraponline commented 5 years ago

Dynamic framework would work for my use case. I don't mind either way.

LeoNatan commented 5 years ago

Isn't that already supported? In Detox, we link dynamically to the EarlGrey framework. If so, Carthage could just use that scheme.

bootstraponline commented 5 years ago

You're correct for EarlGrey 1. EarlGrey 1 works fine with Carthage.

EarlGrey 2 changed to using static libraries and is causing all kinds of problems. 😄

LeoNatan commented 5 years ago

Uhm, why in the world do that? iOS 7 support? 😂

bootstraponline commented 5 years ago

I verified using a sample project that moving to a Cocoa Touch Framework resolves the issue with Swift Frameworks. In summary the benefits to moving to a framework include:

I'm not sure how feasible it is for the EG team to make this change within Google.